Codecademy, reading, every day I'm shuffling

So a while back I signed up for Codecademy. I really enjoy doing tutorials, and it promises to teach you how to code in a year. I already know how to do some basic coding, and I thought this would be great as a refresher and perhaps to shore up some of my spotty understanding of how programming works. I'm talking about filling in those BLANK SPOTS, man!

This week I've been going through the first lesson in my spare time (mostly due to a continuous stream of harassing emails from Codecademy) and it's mostly Javascript so far.

So far it's enjoyable. My only real issue is that it's mostly Javascript, when my real love is Ruby, but I don't think understanding Javascript better is a bad idea. And I'll be working on a lot of basic programming ideas, such as arrays, loops, variables, etc, etc, and that kind of practical work has always been the best way to learn for me.

Also here's my profile. Check out those cheevos dude!

In other news, I spent much of last week working with haml and sass. I've got more user experience and web design books to read. Joel lent me Bulletproof Web Design and Designing the Obvious, and I'm excited to dig into both of them. Read all of the things? SURE WHY NOT

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.

Still working on taming Emacs

I find that I often get tripped up by little things when it comes to programming. For example, I was going through that haml tutorial I posted about a couple of days ago, and I wondered exactly how Rails would know to use the haml file instead of the old erb file. After all, I'd already installed the gem and listed it in the Gemfile.

It turns out I didn't have to do anything else. I could have just renamed the .erb file to use a .haml extension. Luckily this didn't take long to figure out, but I've got a history of overlooking things like this that should be fairly obvious.

haml itself is easy enough to understand. Take those dirty div tags for example!

<div class="content">AWESOME CONTENT</div>

Is magically transformed into

.content AWESOME CONTENT

EDIT: Corrected this information, thanks to Joel. In haml, a . signifies a class, whereas a # signifies an id.

There's more to haml than this, but it's an abstraction of XHTML which makes writing code easier and less tedious. I was thinking of taking the time to do a more in-depth tutorial for haml, but instead I'm going to incorporate it into this Twitter Bootstrap for Rails 3.1 tutorial series my buddy Joel sent my way.

I hope you guys like reading about Twitter Bootstrap, because that's absolutely what I'll be blogging about this week.

I've also made some progress with Emacs, and no longer feel lost when trying to do basic things like open recent files. I've definitely got some work to do before I feel really comfortable coding with Emacs, but I don't think it'll take long to get the basics down. I went through the notes I made at Fort Behavior last week and threw them into a .txt file, so I'll just have that open when using Emacs until I don't need it.

How do I Buffer? Also doing a haml tutorial

So tonight I've been working through this tutorial on haml, working on converting Chorenivore from .erb to .haml view files. Everything's going pretty well so far, but I'm having more trouble than I thought since I'm still learning Emacs.

I've been pretty sorely tempted to just install Textmate or Sublime Text, in order to reduce the number of things that are giving me difficulty, but I did promise Gordon and the other Expected Behavior guys that I'd give Emacs a shot. Four days does not qualify as giving Emacs a shot, you lazy programmer!

I'm going to do some more work with haml tomorrow (kind of funny to think that learning how to use it won't be nearly as difficult as learning how to effectively use the buffer in Emacs is proving to be) and I'd like to take a look at the new version of Twitter Bootstrap that came out this week.

So far I'm enjoying CODETOBER. If nothing else, the guilt of not coding and blogging is prompting me to code and blog more. It's also not as structured as I'd imagined it at first. It hasn't been DAY 1: HAML, DAY 2: CUCUMBER by any means, but as long as I'm doing new things, learning how things work and blogging about it, I think I'm on the right track. And it's definitely a good idea to work on things I use for Expected Behavior work, such as Emacs, haml, sass and Twitter Bootstrap.

More Work with Emacs, Plus HAML and Sass

Today I began to get more comfortable using Emacs, and while it still feels foreign, it no longer feels completely foreign. I also appreciate that a lot of Emacs shortcuts are used in many other programs, so something like C-E is applicable outside of Emacs.

We do a lot of pair programming at Expected Behavior, and my buddy today was Joel. We did some design work, which introduced me to haml and sass. These are both things I've been wanting to look into for a while, and I think today was pretty productive.

Honestly, haml and sass aren't that difficult for me to grasp. haml's way pickier about how things are indented than most other languages I've used, but it's easy enough to pick up. Sass is very similar, and messing around with any kind of design always makes me want to do more design.

It feels a bit overwhelming to be learning so many new things at once (Emacs, mostly, but also haml, sass and using Git for source control) but it's also really gratifying and a ton of fun. It's not about being the best programmer in the world. It's about being the best programmer you can be, and getting better every day.

A Beginner's View on Emacs

So first off, I was hired by Expected Behavior this week. I'd been doing some SEO and marketing consulting work with these guys for a while, and this is a fantastic opportunity. I'm excited about working with such a talented group of guys.

A great deal of my first week has been getting this computer set up and doing right. It's already been named Pazuzu, continuing my trend of naming my computers after famous demons, and also a delicious reference to the Exorcist.

That said, Expected Behavior is an Emacs shop. So I thought a great first post for CODETOBER would be about how I got my feet wet with Emacs.

For a long time, I really didn't understand why programmers preferred one text editor over another. But now I'm getting it. My understanding of Emacs so far is it's a text editor (as well as virtual machine, compiler, debugger, and so on and so forth) with a fanatical insistence on efficiency. If you ever leave home row, you're doing it wrong.

My initial impression? I was intimidated by Emacs, not only by the learning curve (which I understand is steep) but also by its reputation. But I don't want to be put off just because Emacs is 40 years old and doesn't work the way text editors I'm more familiar with do. If I can get past this steep ass learning curve, think of how POWERFUL I will become!

I haven't done much with Emacs so far, but my goal for this week is to get a few basic commands memorized: opening files, saving files, going to a certain line, etc. I estimate there are probably around 10 to 15 command I'll definitely use a lot of the time. Then I plan to expand the commands I've memorized, and we'll take it from there.

I also understand my friend Miles is using Emacs this month, even though he's a Vim guy. Let's all use Emacs, all the time!

Using Twitter Bootstrap to Render Partials with Tabs

It's been a good week for coding. I've done some pair programming, interviewed at iGoDigital, and dug into Twitter Bootstrap.

Which is actually the topic of this post! WEIRD!

Anyone ever tried using those sexy little tabs to render partials? Basically I'm working on Chorenivore again, and I want a tabbed view of the days of the week, with each tab containing items that are supposed to be done that day. I'm currently thinking of a separate partial for each day, though this could probably be reduced to one partial that simply renders each chore that's been tagged with the day of the week, but I thought I'd make it stupid before I made it clean.

Here's the specific code I'm talking about:

Twitter Bootstrap Tabs

I understand how to switch through actual links just fine using these tabs, but how would you do the same thing with partials? I found this question on StackOverflow that seems to address this, but I couldn't get his example to work.

Here's a link to Chorenivore on Git:

Chorenivore on GitHub

A couple other things. First off, I haven't really used Rails in the last four or five months and it feels so BULKY compared to Sinatra. I'm all "WTF, how do I link to a new view and actually make it do right?"

And does anyone know where I'd find Why's Poignant Guide to Ruby? I feel a book report coming on.

Resurrecting an old project

Have you ever been thinking so hard about a problem that you don't even notice when the music you're listening to has stopped playing? This just happened to me about five minutes ago, while I was looking through the code for my old project Chorenivore.

I'm thinking about getting back to work on it for a couple of reasons. Working on a more concrete app that does a few very specific things is both more useful and easier to do than spending my time coding a game, like Dungeon Crawler. I've tried to find a good to-do application, but haven't had any luck. I've tried Tadalist, ToodleDo and Remember the Milk.

And it's a good idea to work on a project to solve a problem I have.

Problem? I don't like the to-do applications I've tried.
Solution? Make one yourself, dummy!

What I want Chorenivore to be is a simple to-do application that allows users to create single and repeating tasks. I also want users to determine when a task should be completed upon creation.

Then I want a list of the days of the week, which allows users to drill down and see what's due that day. I may want some other visual cues in the future (such as showing how many tasks are due on a particular day, or separating single and repeating tasks) but for now I'll be satisfied with tabs that render partials for each day of the week.

The real thing I think is missing from online to-do lists is the satisfaction of crossing an item off a list. I often find myself making lists simply so I CAN check things off of that list. I'm sure I'm not the only one, so I'm thinking about ways to replicate this, or get close to replicating it with a web application.

How often do you guys do something like this? Dig up an old project you've abandoned for one reason or another? I'm guessing this is a pretty regular occurrence for web developers.

On a side note, I fired up a new Rails application the other day and it's funny how BULKY Rails seems after a solid 3 or 4 months using Sinatra.

CODETOBER, other code-related things I've been up to

As you may (or may not!) be aware, I've been doing some consulting work with the Expected Behavior guys the last couple of months, mostly working on SEO for DocRaptor, but also doing some other marketing work.

This applies to coding because they want a way to more accurately track where their users are coming from, so this week I'm going to look into coding something that will pull various bits of information into a more readable format. Sound cool, right?

I've also got an interview at iGoDigital on Tuesday, for a junior developer position. I interviewed there back in September, but it wasn't a good fit at the time. Now? Maybe a better fit! It's kind of funny. When I first got into Ruby, I wanted to make more money and programming seemed like a good way to do that. Now I'm less concerned about making more money, and I largely want to become a better programmer. Working full-time would definitely help me improve my skills, especially in a team environment. So I'm pretty excited about this opportunity.

I'm still gathering ideas for CODETOBER, since I really need to a) code more and b) blog about coding more. So far my list is pretty sparse, and I'm still open to suggestions if you've got them. What kind of things should I be looking into? What would be worthwhile, or valuable, or fun, or frustrating, or otherwise teach me a life lesson? I'd like to see more developers doing crazy things in February.

Now I think I'll sit down and work on a stupid project. I'm kind of losing interest in Dungeon Crawler (SURPRISE!)

Announcing CODETOBER

Awesome IndyRB meetup last night. I got a lot of great recommendations for books to check out, and then had a ton of fun drinking beers and talking about projects at the Brockway pub afterwards. It's pretty awesome that we get so many new people coming to the meetups, partly because it's awesome to see such interest in Ruby and partly because it's also awesome that I'm no longer the newest coder around. After the meetup, I may have had some beers and spent some time hassling other developers about why they should be blogging more often. And then I realize I haven't blogged in what? 9 days? Who am I to hassle other people for not blogging?

But I've got an idea to remedy this. I absolutely SHOULD be blogging more often, and I'm going to take a page from my friend Miles' book and try to learn something new every day in February and then blog about it. I want to have an awesome name for this month, so I'm probably just going to call it CODETOBER. Also it's a leap year this year. WEIRD!

I've got a list going for things I want to look into or try to understand a bit. Mostly things I've heard mentioned often enough that I want to look into them, or how to use tools I'm already familiar with more effectively.

This list is pretty short, though. I'm definitely interested in learning how to dry up my code, since I feel that's a big weak point for me. And getting more familiar using Git for source control, learning more terminal shortcuts, Sass, Cucumber, HTML5 (since I'm a sucker for front-end design anyway) and I'm interested in getting more recommendations. What do you think would be beneficial to look into? Useful gems, fun tutorials, etc? I'M COUNTING ON YOU, INTERNET!

In more concrete coding news, I hung out with my friend Eli and he showed me how to dry up my Dungeon Crawler code quite a bit. I've now got one method that generates the rooms as opposed to 10 different methods! Still pretty soggy around the edges, though. And through the middle. It's actually mostly still pretty soggy.

Learning How to Abstract Code

In my last post, I was talking about how to deal with coder's block. I've been working on my current project, Dungeon Crawler, for about a month and I'd really hit a wall.

The problem was due to a couple of things. First, I'd gotten a lot of really good advice that I didn't quite understand, and I felt bad that I wasn't getting it, so I was reluctant to ask for more advice. Second, I'd already spent so much time without making any progress that I was getting sick of the project.

But I think I've gotten through my lack of motivation and I've made some progress with this project, but the code is an explicit, redundant mess. So the question at this point becomes is it better for me to make some progress coding in a way that I know is bad, or to not make progress at all?

Obviously it's better to make progress (and I did learn a bit about YAML tonight, so it's not entirely a wash) but it's about time I got better at writing code. I've noticed a problem with the way I write code: I'm far too heavy handed and I repeat myself too much. I need to get better at abstracting my code, so that's my current goal.

Maybe this is easier said than done, but at least I'm losing track of time while coding again, right?