haml, sass, North Carolina and Book Reports

Hey remember how I was going to do some new code related thing every day in February, and blog about it every day? And then I didn't update this blog for three weeks? WHOOPS! CODETOBER is dead in the water, but I'm still coding. I promise!

So here's what's been going on. My new schedule has proven to be too busy to blog or work on other things as much.

Last week most of Expected Behavior (minus Michael) headed to North Carolina on a business trip. My buddy Joel (what's up Joel) loaned me several design related books:

Don't Make Me Think by Steve Krug

Don't Make Me Think was probably the most useful of the books I read last week. Tons of great advice about UI design, and common mistakes to avoid. It's a few years old (and the age definitely shows in a few places) but it's still a great resource.

Handcrafted CSS: More Bulletproof Web Design by Dan Cedarholm

Handcrafted CSS is definitely my favorite book I read. I've always loved web design, and I've always wished I knew more about it. Last week was a great chance to work on my design chops, and this book explored graceful degradation, css frameworks and other easily applicable ideas.

Fluid Web Typography by Jason Cranford Teague

Fluid Web Typography is mostly about typography (WEIRD) and while I still haven't finished this book, I've been interested in fonts and typography for a few years now. I'm sorry I can't provide a more in-depth book report on this one.

I read through Don't Make Me Think on the way to North Carolina, and Handcrafted CSS on the way home. I also started Fluid Web Typography, but that was enough reading for one car trip.

I spent a lot of time working with haml and sass last week, so I don't want to give the impression that I'm not coding these days. I don't typically enjoy reading through less practical books, but I picked up a lot of great ideas from reading through these books. And I've always loved web design, and getting to work on redesigning our product StatRaptor was pretty awesome. I'm not as far along as I'd like to be with the redesign, but I've made a lot of progress.

And I'm still using Emacs, since it's not as intimidating now that I know how to do some basic things like open and save files, switch buffers, kill buffers, and so on. I still feel I'd be a bit more productive using TextMate or Sublime Text, but I don't think Emacs is tripping me up as much as I thought it would a few weeks ago.

So that's where I am with coding now. It's awesome to work on interesting problems. But that's what coding SHOULD be about, right?

Lastly, I am absolutely STARVED for more book recommendations. I'm planning to finish up Fluid Web Typography, then dive back into the Pragmatic Programmer. What other books should I be reading? I'm especially interested in web and user interface design books, but anything, anything, ANYTHING you've found valuable is highly appreciated.

More work on Skyrim Stories

Today I finished up Skyrim Stories. If you'll recall, last time I posted about this project, I was looking for a way to strip out #skyrimstories from the posted tweets as well as a way to make the usernames into links to that poster's Twitter account.

My friend Matt sent me to W3 Schools to learn how to use string replace with Javascript. Took me a minute to figure out how this worked until I realized I needed to call a string replace method on the strings BEFORE they were collected into an array.

I was able to use Twitter Anywhere to make usernames into links. Plus it's got a slick hover card feature with a +Follow button. This API is easy to understand and did exactly what I wanted done plus a few extra things.

For the most part I think I'm done with this project now. I might tweak it a bit here and there, but I think it's pretty solid for what it does. And it's time for me to get back into some Ruby work, anyway.

Navigation methods in Rails

I may not always feel like coding, but most of the time if I sit down to code I get warmed up and quickly forget I didn't feel like coding. Today was one of those days. I didn't feel like coding, but I took a look at my to-do list and figured "Hey, I can at least knock out some of this easy CSS stuff, right?" I try to live by a code of "Rails every day".

With that said, here's a little problem I've got.

Here's how I currently have a Back link written in my Menu partial:

<%= link_to 'Back', characters_path %>

The problem is, I render this partial on every page, and so the Back link shouldn't always point to characters_path. I thought an easy solution to this would be to write the code like so:

<%= link_to 'Back', :back %>

This returns the user to the last page viewed, which is closer to what I want, but then I run into some irritating navigational issues. Say you were looking at a Character's Items, and created a new Item, then hit the Back button once it was created. Since I'm rendering the form in the Items view page, it simply takes the user back to the previous view, showing a form with blank fields. So here's my question:

Is there an easier way to handle this? A better method than :back? Should I simply make two versions of the menu partial, each with a separate back link? I don't think I'll need more than two. The menu partial rendered when viewing a Character will want to point back to characters_path, whereas every other page (Items, Skills, and so forth) will need to point back to the Character view page. Maybe I'm overthinking this, considering it's just an extra partial, but I'm thinking there might be a better way to handle this. Imagine if I wanted five different menu partials, or twenty? I think it's better to think of more abstract solutions that can be applied to multiple scenarios.

Css, page design and Rails applications

I think a lot about function and form when I'm coding. I hate looking at the default black text on white body when working on an application, so I usually do some basic styling early in development. I definitely tend to get bogged down with CSS, spending entirely too much time adjusting margins, padding and other granular details, but I don't think styling can be entirely separated from the function of an application.

For example, I created a basic navigation partial, wrapped it in a div and styled it to appear at the top of all the pages in my Manticore app. I'm not sure how this will change in the final version, or if I'll keep it at all, but it certainly helps out right now, when I want to quickly switch back and forth to test navigation or to see how a change in the code works. Or if it works at all!

How do you work with styling when developing a new application? Do you leave it until the end, or do you do some basic styling and then polish it up later? Do you have someone else do it? I know it doesn't make sense to style something that may not be included in the final version of an application, but I'm not sure how other developers work when it comes to basic styling.

Agile Web Development with Rails did styling early on in the development, with some minor tweaks here and there later. It was coming from the perspective of working for a client who wanted an e-commerce site created, so that may have had something to do with getting page styles hammered out early.

Ajax and CSS with Rails

So the section I finished up in Agile Web Development with Rails walked me through adding Ajax functionality to the Depot shopping cart application. First I move the shopping cart into the upper left of the sidebar, then added a notification whenever an item was added to the cart without reloading the entire page. Sorcery!

However, the :blind_down visual effect I was using had some issues. Take a look:

Yuck! What are those disgusting bars doing there? Messing up my beautiful flashing green Ajax notification, that's what! There has to be a way to get rid of those. And there is!

Here's the solution. I know the Ajax notification is going off in the shopping cart table. And I know how it's styled in my depot.css file. These are pretty good clues for figuring out how to get rid of those bars. A quick Google search later and I find a little command called border-collapse.

So I just throw that into the css for the cart table:

#cart table {
  border-top: 1px dotted #595;
    ...
    border-collapse: collapse;
}

And here's the result:

Easy enough!

I find myself drawn into doing some styling whenever Agile Web Development is working on it. Styling should really be left until functionality is hammered out, but I like this approach. I like messing around with padding, margins and color schemes. On the other hand, this ties into something I had wrong about coding for a long, long time. I always kind of assumed programmers had a lot more memorized than they do. Now it's apparent that coders memorize methods they use a lot, but still have to look up quite a bit of information. The important thing is understanding how an application works, having a plan to accomplish what you want done, and knowing how to find the specific information when you need it. So in that case, yes, this DOES pertain specifically to Rails and not just CSS!

I also ran across this page while I was searching for Jquery examples. Seems like a good resource.

Lightening the overload

The longer I work with Ruby on Rails, the more things become clear to me. The more I understand what various acronyms stand for, what they do and how they work. Here's an example, torn from the pages of REAL LIFE:

I work for an e-commerce website, mostly doing SEO work, photography and editing products for the store. The IT manager recently changed our shopping cart because customers were having problems with the Ajax based shopping cart. Before this weekend, I didn't have a clear understanding of what Ajax was. I assumed it was another coding language like Ruby, but it turns out it's just a tool used in web application design. It stands for Asynchronous JavaScript and XML and Agile Web Development had me use it to create an indicator that the shopping cart has been updated in the application I'm working on.

So what have I learned this weekend? I got familiar with Ajax, what it can do and what it's used for (not to mention what it actually IS) and it's given me a better understanding of how everything, from development to design, works together. I first got interested in web design a few years ago, when I fell in love with CSS, and learning Ruby has been nice because I've had to learn how to implement CSS within a Rails application.

When I got started with Ruby a few months ago, I felt like there was a ton of information to process and somehow wrap my head around. That's still true, but the information overload gets lighter every day.