Thursday, April 30, 2009

On Learning

In a previous post, I mentioned that in some of my spare time I like to give private music lessons to kids here in Columbia. Well, that part of my life is now temporarily closed as the demands of my business continue to grow leaving me very little "spare time" left over. It's been tough having to tell each one of my students that I'm not going to be working with them any more, because I've really enjoyed working with all of them and have kind of become attached to it, and as I said goodbye to each one I would find myself thinking about how much they had improved since we started working together. Now I'm not going to take all the credit for that, because they are the ones who practiced, so they are responsible for their own gains in skill. However, I feel that something I was doing worked right, better in fact that my previous experiments in the field of teaching.

What was the biggest difference this time around? Well, my approach to teaching in previous years could be summed up by saying "These kids don't know very much yet, so we'd better scale down everything we're working on to make sure it's not overwhelming and just learn a little bit at a time". That could be compared to my approach this year, which was more along the lines of "This kid already knows how to do X, so let's find something they aren't good at yet and specifically pick a piece to work on that requires that skill". Although the evidence is anecdotal, my experience seems to show that people learn better when they are challenged than when they are coddled.

There are three reasons I can think of that support this idea:

1) slow going is boring

Picking up a little at a time is a quick way to lose interest in anything. This is why I still don't speak Russian very well. I really want to learn Russian, but I've been trying to just spend a couple hours a week on it, reviewing many of the words I already know and just adding a few more. You know what? People who go participate in an immersive language program learn fast. People who pick up "Russian for Dummies" and peruse it a few times a week don't, they just get a nice paperweight that looks good on their coffee table.

2) harder to achieve = more satisfaction

Since most of the readers here are programmers, I can feel confident that this point will garner support. If you are trying to tackle something tough that you've never had to deal with before, then your feelings upon success are made up mostly of excitement and joy. If you just finished coding up another CRUD application which you've done 100 of before, your feelings are probably more of relief than anything else. Difficult and new challenges produce satisfaction that makes you want to come back and do more.

3) expectations cause results

This is probably the most important thing a teacher can do. If you expect your student to make minimal progress, and you convey that expectation in the assignments you give and in your assessment of their work, than they will definitely make minimum progress. If, on the other hand, you expect more out of him than even the student himself thinks he is capable of, he will tend to make strides that would surprise anyone because when he is working he is bolstered and driven by the fact that somebody else who has authority in this subject believes that he is capable of doing what he's been assigned. It's amazing, but true (at least in my limited experience).

So as I said, I'm sad to leave this part of my life behind for now, but the lessons that I have learned from it are worth taking with me into other parts of my life. If I want to pick up something new, I think the best way to go about it would be to pick up a challenging project (for my level), dedicate a good amount of time to it, and expect more out of myself than I think I'm capable of. In fact, I'll go so far as to say this would be a good way for you to learn anything too.

Tuesday, April 28, 2009

Net::HTTP and SSL

Just ran into an interesting problem today that I thought I'd post the solution for. Everybody knows about the net/http library, it's a core bundle that lets you do web requests. Well I was using it for posting to an experimental web service a friend had set up, and I ran into a problem. Here was my code:

url = URI.parse("https://someaddress:443/web/service/path")
xml = generate_some_xml
request =,{"Content-Type"=>"text/xml"})
http =, url.port)
response = http.start {|http| http.request(request) }

Seems like it should have worked, but I kept running into this message:

wrong status line: "\025\003\001\000\002\002"

after googling around a bit, I figured out that this error message comes up whenever you are trying to connect to an SSL enabled site with plain text. I figured that, like curl, if you used "https" in your url, then you were telling the library that you wanted to use SSL. Well, that's not exactly the way it works. Although I put my "https" into the original url, when it gets passed into the HTTP library on line 4 of my code up above, I'm just handing it the host and the port, not the protocol. This requires the use of an aditional line of code:

url = URI.parse("https://someaddress:443/web/service/path")
xml = generate_some_xml
request =,{"Content-Type"=>"text/xml"})
http =, url.port)
http.use_ssl = true
response = http.start {|http| http.request(request) }

there you have it. Hopefully by finding this post, you figured this out a lot quicker than I did.

Friday, April 24, 2009

Improving your Rails-Fu

This month I've been making a conscious effort to improve my competence with the Rails stack. It's not that I feel I'm a bad developer (nobody feels that way, not even bad developers), it's just that the last time I'd been really honing my craft was around rails 1.2, and it's been a while since then (2.3 just released recently). I knew there were some major changes out there that I wasn't taking advantage of, and that there were several things I could improve upon. This was evidenced both by my lack of experience with things being discussed on the rails core list, and the reluctance of other developers to contract in for work on my codebase. Something had to give.

So I went to the same place I always go when I want to work on my skills: The Pragmatic Programmers. I'm not affiliated with these guys in any way, I just really like their stuff. In this instance particularly, I selected a series of screencasts called "Everyday Active Record" done by Ryan Bates of Railscasts fame. Sort version of the story: they were excellent.

I have been a subscriber of the Railscasts feed for sometime, so I knew that Ryan was good at this stuff, but I learned quite a bit from this series in particular that made me slap my forehead as I thought about all the problems they were discussing that I had gone and wasted time trying to solve myself when it was BUILT INTO ACTIVE RECORD THE WHOLE TIME.

A good example of this was named scopes. If you are a Rails developer, you've probably heard of them already, and you're right now navigating away from my article. That's fair, I should have been keeping up better with the industry. Believe me, it didn't take me long to dig into my code and start name_scoping everything more complicated than matching on one column.

If you are like me and HAVEN'T exactly done a stellar job of following the developments in the rails stack (this was introduced in Rails 2.1), you might not know what I'm talking about. Let me point you to a good article on the subject. Read it. Cool, huh?

There's lots more, with easy to follow examples, and at $5 a pop they're a pretty great deal. Do yourself a favor and check them out.

Friday, April 17, 2009

DRY up your views with HAML

About 6 months ago, I read an article about this great templating engine called HAML. I thought I might try it out. I didn't.

Giles mentioned it back in January. I read that article. "Oh yeah!", I thought. "I read about this! it's cool, I should give it a try!". I didn't.

Daniel Morrison gave it a review in February. I read that article too. He said it makes html unmaintainable for non-rubyists. I thought I should see for myself. I didn't.

Yesterday, Ray Myers (employee #1 of my startup) mentioned that he had found this thing called HAML and wanted to try it. I tried it.

Good things happened. My templates got short. I liked reading my markup. Everything was concise, kind of like this blog post.

Wish I hadn't waited so long.


Thursday, April 9, 2009

Profitable on Paper

This year has been my first year as a startup founder, so I'd never attempted anything like this before. In my previous jobs, I got a paycheck every 2 weeks, just like clockwork.

Now, being in the midst of a cash crunch, I sometimes miss that security a little. Not enough to want to go back to being chained to an office working on something I don't care about, mind you.

You see, my company has performed services, and invoiced for them, in amounts that would keep our heads above water. However, some of our clients tend to take upwards of 90 days to pay up. If you consider receivables our situation looks pretty great, but without cash in the bank it means almost nothing.

I wrote a post a few months ago that said "Customer Service is King". I think that in light of new information, I'd rank Customer Service as more of a prince or duke. The real king is cash, and managing it's flow is a major art form.

Some things I've learned about managing cash:

1) slash expenses everywhere, all the time. Any money you aren't spending is money you will have in reserve for things you might suddenly be forced to pay for. Don't cut corners, though. Angry customers soon become non-customers.

2) You are an expense. The less you can live on, the better for the long term.

3) Early on in a startup, cash is scarce, so your time is less precious than your money. Spend time negotiating deals or discounts. It's well worth it.

I'll post others as I think of them, but the main thrust here is that as long as you have less than 6 months of operating expenses in reserve, one of your main jobs is to watch what money you have like a hawk.