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!)