Roommate App Development Blog

Testing Roommate App

Heff — Tue, 16 Jun 2009 05:18:21 +0000

It’s been over a month now since launching Roommate App, and for not advertising and not having any kind of marketing website, it’s doing pretty well. I’ve been getting a lot of good feedback/requests as well. I kind of burnt myself out a little on the project getting it launched, so I took some time off, but I will get to everything eventually. Before I get too deep into new features though, I need to develop the test suite.

Coming from a PHP background, testing is new ground for me (not that testing isn’t done in PHP, but it’s not nearly as prevalent as in the Rails community). When I say “test” in this context, I don’t mean clicking around through the app in your web browser and making sure all the links work, etc. I mean writing more code that makes sure the code you’ve written works (sounds like an endless cycle doesn’t it?). The benefit of doing this is that you can make changes to your application, then run all your tests to make sure what you just changed didn’t break something somewhere else. I’m probably not explaining it very well. Judging by the Wikipedia article, I guess you would call this “Regression Testing”.

Anyway, at this point Roommate App has very low test coverage. The goal would be to reach 100% test coverage, and it’s probably under 5% right now. So I’ve got some work to do. The testing guide at rubyonrails.org was a good starting place for me. It gave me a good overview of the basics and the reasoning behind it. If anyone knows additional resources feel free to suggest them.

While the guide was a good start, Sevenwire (my company) actually uses a lot of modifications to the default Rails app test suite. These include:

Factory Girl — A library for creating test data.
Shoulda — A library for writing more understandable tests.
Forgery — A fake/random data generator (and a Sevenwire original).

So I have a lot of different elements to learn, but that’s half the fun of this project.

Roommate App Is Secure!

Heff — Tue, 05 May 2009 04:12:01 +0000

Finally got the SSL certificate from Starfield set up. It was a bit trickier of a process because it’s a wild card cert, meaning it covers all subdomains of roommateapp.com as well. These are a lot more expensive too, though not too bad through my reseller account at Heffernan.biz. About $250.

If you want a cheap one, sign up for an account there, let me know, and I’ll set you up for discounted pricing.

Shhhhh! It’s launched.

Heff — Wed, 29 Apr 2009 05:15:32 +0000

Roommate App is live! Shhhhhh. : ) It’s available for anyone to sign up, but It’s not 100% tested, so I’m waiting to tell anybody. For those who find this and try it out, let me know if you find any bugs. Thanks!

Roommate App

Soooo close!

Heff — Mon, 20 Apr 2009 05:41:32 +0000

Very close to launching Roommate App. I’m at a point where I’m cutting back on features that don’t absolutely have to be there for launch, and making sure the ones that are there are solid. I even designed a super simple homepage.

I’ve been hearing/reading a lot about how if you aren’t embarrassed by your first release, you launched too late. I think I’m cresting that point right now. There’s a million things I want to add to the app and refine, but I need to just get it up and let my users (if any) decide what my next priorities are.

Also, I’ve been experiencing a lot of “unperfect” apps lately, so while I want the system to be totally solid, I’m letting go of my need for perfection a little. If that makes sense.

For instance I just wrote about my friend’s parenting website. It’s a great site, and looks totally clean, but there are a lot of kinks in the functionality. I know they’ll get worked out in time.

Also, we recently launched a video encoding app, and we still have a long way to go before I’d consider it a great user experience from beginning to end. But the point is it’s up and people are using it.

On the other hand, we just finished KDQOL-Complete, and while I’m cautious to say it’s perfect, I don’t think we could be happier with it.

Anyway, all that said, Roommate App is coming very very soon. I’ve told myself if I can’t get it launched before I leave Wisconsin in 2 weeks, I have to abandon the project entirely. Obviously I don’t want that to happen, so one way or another it’s going live. Can’t wait.

RESTful CSS Update

Heff — Tue, 07 Apr 2009 03:29:11 +0000

Quick update pertaining to RESTful CSS, a method for organizing CSS I wrote a little while ago.

I created a few extra helpers for the body tag. I’ve been adding IDs and classes to the body tag in the form of id=”controller_action” class=”controller action”, so I created these methods to both clean up the html, and to add the extra functionality of overwriting “create” with “new”, and “update” with “edit”. This is needed because of the way Rails handle form errors. Here are the methods.

def body_id controller.controller_name + "_" + { "create" => "new", "update" => "edit" }[controller.action_name] || controller.action_name end

def body_class controller.controller_name + " " + { "create" => "new", "update" => "edit" }[controller.action_name] || controller.action_name end

The body tag would then look like:

No more dashboard

Heff — Sun, 05 Apr 2009 05:45:56 +0000

I’m out in Wisconsin for the month of April working in the Sevenwire office, and getting a lot done. Including getting very close to launching Roommate App. Just cleaning some things up, and tying up some loose ends, though it feels like I’ve been doing that forever now.

My latest big change in the app has been replacing the “Dashboard” tab with a “Roommates” tab. After the last major overhaul I did with Nate where we added subdomains, some new concepts were added that I didn’t have a chance to think about within the scope of the entire app. This included the concept of Roommates playing a much bigger role in the structure of the app itself (who’da thunk?). In Rails terms, they got their own controller (though it kinda took over the Users controller). Anyway, now that I had chance to step back and look at all the concepts as a whole, I realized the whole dashboard section was just the missing index (listing) and show (details) pages from the roommates controller. So now they’re combined into one.

Also, I may be dropping the “Home settings” tab as well, which brings me down to two tabs, Bills and Roommates. How simple is that? It’s crazy how much thought has been required to make this app so simple. Hopefully other people think it is too. If not, they should see my first version.

ActiveForm part 2

Heff — Thu, 19 Feb 2009 08:46:58 +0000

Just following up on my own internal discussion from last night about my ActiveForm javascript library.

I started switching everything to extend the elements themselves instead of building the functionality into separate objects. One thing I found was there was no way extending the form element was going to work. There would be too many name space conflicts. One of them being “name”. The form already has a name, so if you were making a form for a user, it would possibly try to make “user.name”. That would be bad. So that was out.

As far as the inputs themselves, that went more smoothly. I’m not trying to add dynamically generated methods to those objects, so there’s little problem with name space. In fact, switching allowed me to drastically clean up my ActiveForm class. Before I had to use eval() to embed certain functionality into an input, but once I was extending the input directly this wasn’t necessary anymore.

I’m really liking how this is turning out, and I’m looking forward to using it on future projects.

ActiveForm

Heff — Wed, 18 Feb 2009 06:03:20 +0000

I’m writing this post mainly to think through a javascript library I’m working on.

The library is called ActiveForm, and the concept is similar to how ActiveRecord objects in Rails interact with the database. ActiveForm, or rather its children ActiveFormField objects get and set values from actual input elements, while utilizing railsish callbacks. Including:

before_validate()
validate()
before_set()
set()
after_set()

before_get()
get()

This allows me to do something like this, where I format a the value as an amount before setting actual element’s value:

before_set: function(value) {
return this.format_as_money(value);
}

Whether or not this is the best way to do things, I couldn’t tell you. I’m no javascript genius. But I’m having fun writing it and I’m enjoying they syntax it creates.

A question that I’m asking myself now, that I know will come up again, is why didn’t I just extend the form elements themselves? This would be similar to how Prototype does with “$(input).getValue();“. So I’m documenting it here so when I forget why later I can look it up.

For starters, it had to do with how I was thinking of the objects versus the actual elements. In my head, the elements were like the database in Rails and the objets were like ActiveRecord objects. ActiveRecord objects cache and process database values and only call and update the database when necessary. Forgive me if I’m explaining Rails all wrong, I’m still a relative newbie.

This metaphor loses a little when you know that the user edits the elements directly, but ignore that part. It doesn’t actually make that big of a difference since the ActiveFormField immediately grabs the value and processes it.

Another reason would be containment of the ActiveForm methods, so they don’t conflict with anything else. I don’t know if this is a huge problem though.

At the moment, I can’t think of any other reason, so I may have to try switching and see what I run into. I think it’ll be a lot of work though.

And now somehow hours have gone by in a blink, and I have to go to bed, where I’ll stare at the ceiling and think about this all night…

Progress!

Heff — Mon, 16 Feb 2009 06:46:25 +0000

Got a lot done this evening. Redesigned the dashboard and roommate views and did the html/css for both. Also got bill splitting and payments sending out confirmation emails.

That covered a good chunk of my to-do lists, so moving along steadily towards my new goals and launch date of April 1.

I have way too many ideas for this app, and the hardest part is staying focused on just getting the essentials done so I can launch it.

New Deadlines

Heff — Sat, 07 Feb 2009 07:05:07 +0000

Yeah, I know this is getting old, but I’ve got some new goals. I’ve been side tracked by some other projects, including Bryan Clay’s website, but I’m sticking to these this time…really.

Launch by April 1. Online payments by May 15.

The second could be a lofty goal, but we’ll see. Brandon set up a Basecamp project on the Sevenwire account for Roommate App, so now I get to go load it up with milestones and to-dos.

My problem so far I think is that I’ve been letting my self get overwhelmed. I had a list of everything that needed to be done, and some overall deadlines. What I need to do is divide and conquer, setting deadlines for each piece. I think that’ll help.