Pretheory is official

After years of dreaming, planning, thinking, plotting, learning, working, and saving…
Pretheory, LLC is now a registered LLC entity in Colorado!

Rails and SCRIPT_LINES

After reading a great tutorial on debugging in Rails with ruby-debug, I inserted the following line at the end of my config/environment.rb

SCRIPT_LINES__ = {} if (ENV['RAILS_ENV'] == 'development' || ENV['RAILS_ENV'] == 'test')

which had been working just fine for me. Ruby-debug is a great debugger and has helped me track down a lot of tricky issues (and works more consistently for me than the built-in debugger within RadRails).
However, today I ran into a weird problem – tried to install rcov and the rails rcov plugin. But when I tried

$ rake test:units:rcov

I got the following:

...
...
Loaded suite /opt/local/bin/rcov
Started
....................................
Finished in 4.366043 seconds.
36 tests, 114 assertions, 0 failures, 0 errors
+----------------------------------------------------+-------+-------+--------+
| File | Lines | LOC | COV |
+----------------------------------------------------+-------+-------+--------+
+----------------------------------------------------+-------+-------+--------+
|Total | 0 | 0 | 0.0% |
+----------------------------------------------------+-------+-------+--------+
0.0% 0 file(s) 0 Lines 0 LOC
No file to analyze was found. All the files loaded by rcov matched one of the
following expressions, and were thus ignored:
...
...
...

What’s going on here? After playing around for awhile, I tried commenting out the SCRIPT_LINES line above and bingo! everything worked.
After a bit of searching, I found a comment on this ruby-debug tutorial that states that the SCRIPT_LINES constant no longer needs to be defined for ruby-debug to work. I briefly tried ruby-debug without defining the constant and everything seemed fine.
So if you find yourself facing some weirdness with rcov or any other Rails plugin, send that SCRIPT_LINES constant packing and see if that helps.

Bank of America apparently dislikes customers

This isn’t directly related to startups, but since it is the loudest megaphone I have – DO NOT, under any circumstances, bank with Bank of America!
Well, I guess it’s a little bit related, because it will be a cold day in hell before I use any of BoA’s small business services.
I signed up with BoA freshmen year of college and have never switched since they were generally just barely good enough and I didn’t want to go through the hassle of switching.
I tolerated their terribly designed online banking. And I handled the fact that they didn’t have their shit together so I had to close my Missouri account and open up a brand new account in Seattle, WA when I moved (Washington in on a different system due to a merger. A merger that happened years ago and yet, they still have not integrated the systems as I write this).
But today was the last straw. I have a BoA checking account and a BoA credit card. Last month, I tried to pay of my credit card with my checking account. You know what? I messed up. I thought there was slightly more money in my checking account, and I overdrafted it.
Like, I said, my fault. No excuses. And I was willing to pay a fee for that. I looked at the credit card fee – $39 fee. Ouch. I looked at my checking account – $20 fee. Ouch again.
But the real kicker was the additional $35 fee on my checking account for the same charge. OK, enough is enough.
I called up BoA checking, asking why there was a second charge (now that I think about it, I’m also pretty confused as to why the fees were different, but whatever). They said I tried to post it twice. Well, I didn’t, and my online account log for the credit card shows that.
So I figured the credit card division had posted the charge twice. So I asked to be transferred to them. Nope – they claimed they posted it once.
So I got transferred back to the checking division. I explained that the credit card division (of their own company!) states there was no second transaction.
They offer to take off the $20 instead of the $35, effectively charging me $15 for their error. And of course, this is a courtesy to me, but for the record, they won’t remove charges in the future unless it’s a bank error.
I do my best to calmly explain that, according to their credit card division – it is a bank error. No dice. I ask talk to a supervisor, who explains that it’s not their fault, and since I’m a long-time and loyal customer, she’ll take away the $35 charge … but that’s my one courtesy charge removal for the next year, because, after all, it’s my fault according to them.
You know what? That’s fine, because I won’t be banking with BoA by next week.
You know what’s really amazing? The entire time I talked to two different divisions and nicely explained to them how I was getting screwed, each division claimed their innocence, blamed me – and never ONCE did I hear anyone offer to sort it out with anyone else in the company. I’m alerting them of their error, and no one had any interest in determining the cause of the error – which might just save their customers frustration in the future.
Well, Bank of America, I know one small customer like me means nothing to you, but I hope that the money you made today is worth losing a customer for life. It would have been so simple to turn this situation around and make me sing your praises, but instead, I’m going to tell everyone I know about how you’d rather resort to finger pointing than solve a customer’s problem.
===============================================
Update: After emailing BoA’s customer service several times (and waiting days for them to reply), I finally got an answer to my question.
It turns out that this was, technically my mistake. Let me explain: buried in my cardmember agreement, it says (according to the customer service rep, still trying to track down a copy so I can check)
“if a payment is returned one due to Insufficient Funds, we will automatically send it for a second attempt to be cashed. If the payment is returned unpaid a second time, we will then remove the credit from the credit card account.”
As I said earlier – my fault. I signed the agreement, and didn’t know the details of the policy closely enough. That said, I think I have still learned a lot about BoA, and none of it is flattering.
Lesson 1: BoA’s customer service still sucks. It took me over ten days to get someone who could actually clear up this issue, and I had to talk to or email over five different people. Everyone before the last email was unwilling to track the issue down.
Lesson 2: BoA’s customer service is ignorant of their own policies. The credit card representative insisted multiple times that they would not have, under any circumstance, tried to post the payment twice. As it turns out, that’s exactly what they did.
Lesson 3: BoA is intent on screwing customers out of money. I’ll say it again – I overdrafted my account and I signed the policy. It’s my fault. That said, to have a policy that charges your customers $90 for one mistake is not a very customer friendly policy, especially when the overdraft itself could not have caused more than a few dollars of cost to BoA, at max. I would have paid $20, $30, even $40 without complaint. But $90 is ridiculous.
I’m certainly happy in my decision to leave BoA for good.
===============================================
Update 2: My brother called me recently asking me whether he should join BoA or another bank. I don’t remember what the other bank is, but the string of profanities I unleashed into the phone convinced him to stay away from BoA.

We have a winner

For better or worse, we’ve decided to go with Ruby on Rails for our prototype. Why? In short, we think RoR will let us finish a version 1.0 very quickly – and that means we can start getting real feedback from early users sooner rather than later.
Django had some very nice features, but ultimately, it didn’t seem like a clear winner over Rails (both had pros and cons) and, probably most importantly, we know and prefer Ruby over Python. That’s not flame-bait, it’s just a personal preference (I heart blocks). YMMV.
Of course, the scaling issue is in the front of our minds, especially with the recent high-profile case of Twitter (and certain responses). Are we concerned? Yeah. But, scaling would be a nice problem to have, since it would imply that we actually have users. In all likelihood, scaling problems are still many months out.
But, when it comes up, our plan for scaling is four-fold – first of all, we’re hoping the Twitter experience motivates the RoR community to look more into scaling (particularly using multiple databases effectively), and we can reap the benefit of that work in few months (hey, maybe when we understand the issues better we can write something ourselves).
Also, JRuby is looking more and more promising. Not only does it look like it’s going to be as fast (or maybe a bit faster) than regular Ruby, but, since it runs on the JVM, we’ll be able to integrate it with faster, statically-typed languages on the backend (Scala, anyone?).
We might also try to use faster, statically typed language on separate machines and connect it to the front end using web services. I’m sure there is some overhead here, but on the plus side, it’d force us to develop a nice web API sooner rather than later, which is something we want to do anyway.
Failing that, we can always rewrite the damn thing in another language. It would suck, but hey, it didn’t kill Reddit.

No dice

Unfortunately, our proposal was rejected by TechStars and Y Combinator. We wish those who were selected all the best. And thank YC and TS for considering our app. Now, we’ve got a lot of work to do…

Of prototypes and tracer bullets

While we’ve been waiting to hear back about funding, I’ve been spending my time working on a prototype of our app. At least that was the plan.
My initial intent was to do a proper prototype. In other words, a throw-away version that I could learn from. In one sense, I was successful – the code I wrote let us get a good understanding of potential problems and sparked some great discussions. I feel like I understand the project a lot better now than when I started.
But, as I wrote the code, a funny thing happened. I got a few features done, but I wanted to flesh out the app a little more. So, I wrote a few tests to ensure I didn’t break core functionality and then added a few more features. Then I noticed some bugs that broke main scenarios, so I fixed those. Then I added another test, another feature, and fixed another bug. And somehow, little by little, the code became less like a prototype and more like a tracer bullet (the distinction is described in The Pragmatic Programmer).
Like any startup, our goal has always been to release early, and the iterate quickly. I started the prototype with that goal in mind. However, at this point, it’s surprising to me that the role of the prototype changed out from under me. We’ve had to ask ourself – should we throw away the code and write the production version from scratch, we we initially planned? Or use this code as a foundation for our real implementation?
It wasn’t immediately clear to us what to do – going down either path requires some work to get to a code base that we will be comfortable working with. The more we thought about it, the more we found that the answer lies somewhere in the following questions.
How much code have you written? Clearly, if you’ve written a lot of features that took a long time to write, you’ll prefer working with the existing code.
How good is the code? Although Joel famously stated that rewrites are a terrible mistake , he’s talking about mature software that already has a lot of bug fixes. If your code doesn’t have many fixes (and therefore still has a lot of bugs in all likelihood), has an architecture you know is flawed, or is just fully of hacky code, then perhaps you should lean towards a rewrite (you’re going to have to do a lot of refactoring just to get it in a good state anyway).
How many tests have you written? If you don’t have any tests, chances are you’ll have to refactor the code just to get the code under test. Then you’ll have to refactor more to get the code clean. It will probably be less work just to rewrite from scratch, baking in tests from the beginning. On the other hand, if you already have tests, refactoring will likely be a lot cheaper than a full rewrite.
What language/platform are you using? Clearly, if you wrote your prototype in a different language/platform than your real app, you’ll need to do a rewrite. We wrote our prototype in Ruby on Rails, because I know Ruby pretty well and knew that we could get something running quickly with Rails. Although RoR was a great system for writing a prototype quickly, we’re not sure if it’s going to be the fastest way to get a version 1.0 release (any advice on this is appreciated).
The lesson I’ve learned is to have specific goals in mind when writing a prototype. What exactly are you trying to learn from the prototype? How many features do you need to write? Which features can be faked? What can you avoid testing? If you don’t have some answers beforehand (both for yourself and others), you may end up writing something entirely different than you intended.