All aboard! TOOT TOOOOOOOT

Uh oh, who just cracked open Rails and created all the necessary files and folders to begin developing his very first Ruby on Rails project? Me! I did. (This guy)

So I know I said I was going to look into getting CGI scripts to run on my web space so I could throw Loudmouth up and let people check it out, but to be honest that sounded BORING. So I took a look at chapter 13 in Beginning Ruby (I'm almost done with this book, weird!) and it's about developing a basic Rails app.

I haven't done much with it yet. I really just read through the first few pages of the chapter, got the framework set up for the project itself and sat down to blog about it. I'll begin in earnest tomorrow evening, when I've got more time to sit down and dedicate myself.

Have I mentioned how I never thought I'd be even remotely interested in back end work? Funny how things change. I'm excited to begin working on this project. I want to understand how Ruby works on the web, how to integrate it with databases, how to collect, store and retrieve information, how to adapt to user input, EVERYTHING!

Working on Loudmouth

Yesterday I finished up my first fully functional Ruby program: a chat bot! Beginning Ruby likes to call its bot Fred, but I named mine Loudmouth.

So now all I need to do is get Loudmouth up and running on the web. I started to dig into getting cgi scripts to run on my web server, but decided to leave it for tomorrow evening. Once again, I find myself learning non-Ruby stuff in order to work with Ruby. This kind of thing would have seriously intimidated me before I got into Ruby, but I've gotten a lot more comfortable working on back-end stuff.

I haven't been blogging as much, but I haven't been slacking on Ruby. (Not much, anyway!) I've been busy coding and haven't felt like I had much to say about what I was working on. Still, I need to get back into being more diligent with this blog. Writing about what I've just done really helps me retain the information.

The next chapter in Beginning Ruby will introduce me to Ruby on Rails, which is what my friend Eli suggested I look into next. This book has been such a great resource. I downloaded the source files for each chapter and they've helped tremendously, especially as I've gotten into these longer programs. Now it's easier to find out whether I forgot to close a statement or didn't put something in quotes.

Oh I'll test your case, you rogue

I think test cases were designed specifically to give me a headache. This chatbot program I'm developing is going pretty well. I always take it as a good sign that my Ruby studies are progressing when I get a headache afterwards. Or during. Whatever!

Either way, it feels good to be building something that functions. Even though that functionality is limited. Even though the code for that functionality was handed to me. I'm glad the source code was available to download, because after throwing multiple errors I found out I had an extra | in my source code. And I was missing a parenthesis before that. What a slob!

Here's a question: what's the advantage of writing test code rather than simply running the source code and checking for errors that way? My guess is by writing a test code, Ruby is checking that the underlying logic makes sense and works, but if that's the case, wouldn't simply running the source code do the same thing? Is it faster to run tests? More economical for larger programs?

I get the feeling writing test code doesn't make much sense to me now, but it's something more vital for bigger projects where more things can go horribly awry.

Building Loud Mouth

So this weekend I've been working through chapter 12 in Beginning Ruby, which is about building a larger program using the techniques learned so far. The program is building a basic chat bot, and so far I've coded functionality for getting information from a user, switching pronouns and returning the original sentence so that it appears the chat bot is asking a question. I also named the chatbot Loud Mouth.

My understanding is this is similar to how a lot of chat bots work, at a very basic level.

But here's something that's been bothering me. I can't run this kind of program straight from TextMate. I have to run it through IRB in order to collect information the program can manipulate. Is there a way to make it so I can just run it from TextMate, or is there a text editor others use that allows you to do that? I'd prefer just to deal with one open program and I like to run it periodically to see how the changes I've made to the code affect functionality. Or if they break it!

Also, when a user inputs information that is collected with the gets command, where is that information stored? Is it stored at all, or just used immediately by the program and then discarded?

Using class_eval to add methods to a class

So I finally slogged my way through Chapter 10 in Beginning Ruby. It wasn't nearly as helpful or interesting as I thought it would be. I mostly got hung up on MySql for a few days and had a hard time working through it.

I don't think I need to learn how to interact with databases just yet, so I moved on to Chapter 11: Advanced Ruby Features. Aha! Now we're talking. I spent some time working with class_eval, which allows you to add methods to a class dynamically, and exec, which allows a script to run another script.

Here are some questions I've got, though.

What's the benefit of using class_eval to add methods to a class instead of just defining those methods within the class itself? This isn't a temporary definition, right? So it seems like you'd end up writing about the same amount of code, but defining methods within the class instead of adding them later would keep the code more organized.

And when it comes to exec and fork, what's the benefit of using these commands to spread the functionality between scripts? I'm seeing this as similar to using mix-ins. For example, you could have a script that checks the time on the user's system, then either does or does not do something based on that time. It might be useful to run this script from various parts of your overall program and that's why you would want to do it. Am I thinking about this in the right way?

I'm also starting to wonder where I should go once I'm done with Beginning Ruby. The book is already warning me the last section is mostly just appendices and reference, so any recommendations are welcome.

Getting past my MySQL gem issues

So the MySQL gem has absolutely killed my productivity today. A simple command line install didn't work. So I installed macports, only to have my friend Eli recommend homebrew instead. Then I had to uninstall macports (surprisingly difficult, it was like an infestation) and install homebrew. So I finally get homebrew installed, hoping to use it to install MySQL, then use that installation to install the MySQL gem. MySQL was installed, but I'm still having errors with the gem. WHAT!

tldr: the MySQL gem is a headache I don't need to deal with right now, so I'll skip it.

So this morning I've been learning about how to create, document and distribute gems. It seems a bit far-fetched to think I'll be writing code others might want to use, but who knows? One thing I really like about Ruby is the openness of the community: experienced developers are open to helping newbies and developers are open to sharing code that others might find useful.

It feels good to be back in the swing of things and not just beating my head against the wall. This is one of those things I told myself I wouldn't get hung up on.

Working with MySQL and Ruby

Whoa, what's up SQL and MySQL?

Here's something I've recently realized about learning Ruby: I can't just learn Ruby. Ruby is going to be the thrust of what I'm learning and I'll spend the bulk of my time with it, but if my ultimate goal is to make a career change and become a full time Ruby programmer, I'll have to learn other languages as well.

This idea isn't as daunting as it might have been a month and a half ago, before I even had the seed of a desire to learn Ruby.

So here's something I've noticed about working with a bit of SQL and MySQL tonight. Computer languages share a lot of the same ideas. Sure, Ruby is more elegant than something like C++ and more modern than the Basic I learned in 9th grade, but the idea is the same. So the teeny, tiny little snippet of MySQL I wrote tonight was easier to understand than it would be if I hadn't also been working with Ruby for a month and a half or so.

I actually had to cut my database work short tonight because I couldn't get the MySQL gem to install, but I WAS able to write a program that allowed me to write to a database and retrieve information from it. Pretty cool, considering that's what I've been hot balls to learn since I cracked open Beginning Ruby.