I figure that it’d be a good idea to start blogging the experience of building a site from scratch with Rails by a newbie (not that there aren’t a hundred of those already).  Read My Code was done in 24 hours, I figure a week or so, or heck, a day or two per feature, ought to be enough.

I started by breaking things into some steps:

1. Create the Idiom scaffold, model validation, etc
2. User authentication and login
3. User integration (edit your own Idioms)
4. Site layout, look and feel
5. Commenting
6. Tagging
7. More site layout stuff (I’m thinking this might be the hardest part for me, as I am a programmer and not a designer for a very good reason

That’s of course a bit over simplified, and I’m probably missing out something huge, but that’s the current attack plan.  All things are flexible of course.  My grand plan is to code one day, blog the results and anything interesting or challenging that I find. I’ll make sure I push things up to the GitHub project page as well.

• My idea for a memory capture (ie: put in memories of your past) is, I realized, essentially a blog with a better way of adding by date (fuzzy dates).  Really, just a blog.  Do I want to end up re-writing wordpress or movable type again, poorly?
• The ruby-idioms site that I spoke about a while ago appears to have been written already over at http://readmycode.org.  While I applaud the author for getting the site out in 24 hours, he also basically created what I wanted to.  Grrr…..

Now, that’s not to say that I don’t have passion for the projects, and definitely doesn’t mean I won’t still do them (nothing says you can’t create something if it exists already).  Shows the dangers of not committing and waiting, instead of getting stuff done NOW.

Guess it’s just a bummer to get to the realization that my fantastic ideas maybe aren’t that wonderful…. Bleah.

Anyway, keep on coding out there, got some ideas here for some hopefully interesting posts coming up next week as I get better and closer to upright!

One of the big challenges I have myself is that I get mired down in details.  For example, I have this idea to do a Ruby Idioms site, and the setup seems pretty simple.  User login model, an Idiom model, thrown in something like acts_as_taggable-on or whatever’s hot right now, a bit of layout, some begging for real design from some helpful designer(s), a short beta with some real users to flesh out the bugs and fill in the database, and then release, iterate, release, iterate, done.

For a Rails project this isn’t overly complex, hell, an intermediate coder could probably hack that out (up to the design part) in an afternoon.

And yet a week after coming up with, and getting all excited by, the idea of doing it, I’ve only gotten as far as registering the domain.  What the hell is wrong with me!?  Heck, I started this post half a week ago and still haven’t posted it, or gotten around to doing anything more.

So why?

There are a few different reasons why people procrastinate.  I’d put them in a random order chosen out of my brain:

• You’d have to finish if you start
• Easier to sit on the couch and watch the new Blue Ray Alice in Wonderland
• Too many other things to learn first

The last point is the big one for me, and for a few people I know too.  When I say “to learn” I don’t mean that in the “oh I have these awesome new technologies to get through” sort of way, but more in the “well, I can’t write a rails app until I learn rails, but I have to learn ruby first, and there’s all these libraries, and I hear that 1.9 is coming out soon, so maybe I’ll wait for that to be released, and I hear Rails 3.0 is almost out, so it makes no sense to learn Rails 2 now if the next version is only a couple of weeks or months down the road…”

I believe the seminars call this (among other things) the “whoah busy” syndrome.  With a scary task ahead of you, it’s really easy to end up bogging yourself down in the minutia of it all cause if you have to mow the lawn/do the dishes/clean the house/do the litter box/cook dinner/get lunch for tomorrow ready then it’s really easy to put off starting that new project…

That’s my issue anyway, I’m sure it’s not unique, but I don’t want to put any of my own issues on people out there.  I think if you look deep down in your own psyche you’ll figure out what it is that’s stopping you.

Ok, so in the time of reading this and a few seconds contemplation, you now have figured out what issues you have stopping you from getting your stuff done, so what now?

The most obvious is to just do it.  Seriously, close the browser, shut down your RSS reader and open up Vim/TextMate/EMACS/whatever and start coding.

Still reading? Stop, close the browser and get out and do whatever it is you need to do.  Think about that feeling you get when a project is done and how good it feels to tick something off your todo list (legitimately of course, not like this guy).  You’re a lot closer to that ticking off feeling after you start, not before right?

My best example of this from my own past was working with @milesforrest at an early FV.rb meeting and it was just the two of us, and we started into the typical geeking out, surfing reddit, etc.  I put my foot down and said “lets make something”.  We set up the site’s website onto heroku, put it up on github and worked on stuff.  It actually sucked… there’s nothing to show you the difference between having read a bunch of Rails books and blogs and actually coding it.  I did a lot of cursing that day, as all the stuff that should be just super easy turned out to be really friggin’ hard, or at least hard from a “I have no clue how to do this” point of view.

We persevered though, and worked on it and by the end of the night had  a lot better understanding of some of the Rails insides that now (months after this initial ordeal) are second nature and super simple to do.

Moral of the story?  Each journey begins with just one step, and each new web project begins with typing in “rails <projectname>”….

• Taking Responsibility
• “I hate my job”.  “I don’t have enough time”.  “That’s too early/late”.  “I’m too tired to…”  These are all excuses we use all the time.  The concept of taking responsibility is pretty simple.  Instead of making excuses, realize that if you hate your job, that’s because you are choosing to stay at it.  If you don’t have enough time that might be because you choose to watch Lost and America’s Top Model in the evenings, and if it’s “too early” that’s because you are choosing to not get up that early.We all have rationalizations… we can’t quit our job because the economy is in the shitter, and we really like Lost, and we went out with our friends last night so we want more than 3 hours of sleep.  Blah blah blah.  There’s all sorts of rationalizations, but sometimes it just comes down to if you it was that bad, or if you wanted it enough, you’d do it.  Until then, you have to take responsibility for your circumstances (or at least some of them).
• Goal Setting
• Setting “SMART” goals was a major part of these courses.  This means that you need to set goals that are Specific, Measurable, Agreed On, Realistic and Time based.  IE:Your goal has to be Specific, like “I will lose 10 pounds” not “I will lose weight.”  Or “My next job will pay me more than $75,000 a year” not “I will get a raise in my next job”.  Being vauge means your results will be vauge.  Having something specific will give your brain something to lock into.Tied into this is Measurable.  If you can’t measure it, or know where you are in relation to success or failure, it’s harder to achieve.  So making a goal based on something you can measure is needed.  If your goal is to get to Vancouver, you need to know where you are to know how far you have to go yet.  So unmeasurable goals are the touchy feely ones that you can’t tell if you get them or not.If you can’t Agree upon the goals, or if there is any ambiguity about them with the people you’re making the agreements with, they’ll be harder to achieve, or be enforced.

  If you’re not realistic and your goal isn’t Realistic, you’ll just be frustrated.  “Make a billion dollars”, “run a 2 minute mile” or “become a playboy centerfold” is probably not attainable, and you’ll end up frustrated.  Sometimes that means that smaller and more bite sized goals means you get more success and feel better about yourself.

  If there’s not a Time limit on the goals, you won’t be able to know when you are done.  I’m sure I could make a billion dollars given enough time, but saying “I will lose 10 pounds in the next month” instead of “I will lose 10 pounds”, because at the end of the month if you don’t weigh 10 pounds less, you’ll know that you didn’t achieve your goal.  Giving yourself a time limit also gives you a kick in the ass if you see that finish line approaching.

I think that’s probably enough for now.  I know it’s a bit outside of the normal TiR fare, but this sort of thing has been rolling around in my head recently a lot all in related to my own struggles to get stuff done and getting over the fear (not exactly the right word to be honest, more like “super delay and procrastination ability”) of new things like Rails.

If you can use any of this, great.  Set yourself a goal to get something done code wise, even a small one, just to get the feel of it.  Maybe “smart” goals aren’t your style, find something else that doe work.

Hopefully that info will help some of you out there.  Check out LifeHack.org for lots more stuff like this.  It’ll be back to the code stuff tomorrow, promise

Last night I finally broke through this a bit.  Amidst my mother-in-law drilling and cutting (she’s helping my wife put up cabinets) and my brother-in-law on the couch oohing and awwing over heavy equipment ads on craigslist, I managed to get things done.  I figure a bit of post-mortem might help me for the next time it happens.

The two things that I had on my plate were not, in fact, the only things needing to be done, but they were the two things that are fairly isolated and sort of simple.

The first was adding ‘areas’ to my referee site.  Each club has many fields, each field has many games.  I wanted to expand this so that each club has many areas, and each area has many fields, and so on.  Basically this allows you to break up the “Langley” club into say, north south east and west, and assign users to various areas and make things a bit more manageable.  IE: Assignor Bob manages the north zone, while Manager Sue takes care of South and East.

Code wise it’s pretty simple, add a new model, add the “has_many” and “belongs_to” relationships, and create the management pages.  Simple stuff, so what’s the problem?

I think it might have come into the testing part again.  Because I’d have to rearrange some of my queries to ensure that users get the right games from the right fields from the (now) right areas from (breath) the right club, having no testing set up means that I’d have to go to all the pages that access that code, redo the queries, re-test, etc.  Ugh.

The second task that was a real stumbling block was the user and role management.  I had set up user authentication a while back, and if you log in as one of two user types you’d end up being sent to the “correct” page, and the two different controllers (/bids and /assignments) are protected through a before_filter as well, but I hadn’t gotten around to “Management” stuff (editing games, fields, etc) yet.

The big mental block that I had in this area was that I had 3 fairly clearly defined roles, 4 if you include the “unauthenticated” users.  I had

• Referee (can bid on games)
• Assignor (approves/edits referee bids)
• Club Admin (club management stuff)

All the stuff in the User model is geared towards these, a club_id is defined and required, email is required, etc.

The role that wasn’t so easily defined was the “master” admin.  This is the main user that would manage the whole site, set up clubs, and basically have access to everything.  I faced the challenge of either creating a new type of authentication and model (ignoring the DRY principle), putting a bunch of exceptions in (ie: requires validation of club_id unless this user has a role type of ‘masteradmin’) and making things ugly.

I managed to push through the first one, or at least start to.  I’ve managed to get to the scaffolding part anyway.  Also in my lunch hours I’ve started going at the failing tests too.  That’s a whole other blog post though, probably involving me going back to the simplest cases that are in the Rails Tutorial book and figuring out how to deal with speccing out password protected pages

I think I saw testing originally as a really nice thing to do in theory, but something that was quickly glossed over when you have your boss looking over your shoulder and wondering just why your project was late, just write the damn thing.

I actually discovered testing in Perl around 2003 with Test::Unit, when I was working at a company that did an online game site for school students.  I read about testing, grabbed Test::Unit and Test::More and proceeded to do add some rudimentary tests to the model to do things like ensure that instantiating a new User model always created an object of the right type, that sort of thing.

I proudly told my boss this.  His response was something like “neat”, with the unspoken subtext of “why aren’t you doing your work and wasting time doing this”.

Fast forward to the TDD happy fun world of rails.

I’m now a couple of weeks into my referee management site.  It’s got a non-trivial, but not hugely complex set of models and interactions and I want to make some (moderately) major changes in some of the architecture.  It terrifies me (well, maybe terrify is too strong a word) to make these changes without being able to just hit a button and know, know, that everything still works properly.

I started creating my models and controllers based on the Rails Tutorial site and using the “rspec_” syntax.  IE:

script/generate rspec_controller Foo

This creates a set of default RSpec tests.  Of course, the defaults are standard stuff, making sure that creating the object returns the right type of object, etc. Luckily a bit later on in the book there is a section on setting up your first tests.

The first challenge I have to create some of my tests (again harkening back to my “rails makes it seem sooo easy, but when you do it it’s a lot harder” rant), is that most of the pages on the site (that do interesting things anyway) are password protected. So now it’s a trek to find out how to deal with speccing out pages that are password protected to help fix the 24 failed tests I have sitting now when I run ‘spec spec’

So let that be a lesson to you all…. do your testing from the start, and set it up from the start like I should have (and knew I should have).

So my mentor, or more accurately, the guy I bug with annoying noobie Ruby questions, @dkubb, pointed me to the Addressable.URI library.

I started out with his suggestion of:

params[:url] = Addressable::URI.heuristic_parse(params[:url]).normalize

But found it didn’t work quite as I wanted. After a bit of searching some blog posts I found that the function I wanted was the heuristic_parse, which will try to intelligentally create a valid URI.

Since I’d been “in” Ruby for a few weeks now, I figured why not, and hit the ‘view source’ button on the API page. This was the grokking moment. The “thinking in rails” as it were.

The problem I’d had before wasn’t that I didn’t read Ruby all that well, but that I didn’t have a direction to do it. Randomly opening up functions, or the Rails core code, or someone’s library didn’t make nearly as much sense unless you had a reason for it.

You know how they say the best way to learn something is to need to use it (well, someone say something like that anyway)? Well, this was it. I knew what I needed to do (turn “foo.com” into “http://foo.com”, I had played around with it in IRB so I knew it worked, and now I was a mouse click away from being able to read how someone did it.

The heuristic_parse function is only about 30 lines long, and if you can remotely read regexes, it’s competely readable.  Now I have a place to start reading, seeing how other people write code and start learning some of the common idioms that I might be missing.

Short story long, reading others source code is a great thing to do, as long as you have a place and a reason to start, otherwise you may just confuse yourself more.

This isn’t all bad though.  To quote the great @curtismchale:

“getting code out is better than sitting on it forever to make it ‘perfect’”

The idea that has permiated rails from the time I started reading about it in 2004 till now is “iterate”.  So is it bad that I have multiple authentication methods in multiple controllers, all of which do the same thing, when I can just go back and fix it later?

I would say, “kinda”.  The old axiom of “make it work, then make it fast” applies here, but within reason.  You don’t want to over-design, but you also don’t want to under-design.  I think the key to the iterative process is two-fold:

1. Iterating only works if you do it fairly quickly, not say to yourself that you’ll go back and fix it and don’t get to it until the project is over.  From what I’ve seen personally it works best if I:
   • Finish a task
   • Go back and make it work better^{(see point 2)}
   • Or:
   • Work on something else that’s related or could affect the previous tasks design
   • …. then go back and make the first task better^{(see point 2)}
2. You almost need, neeeeeeed a test driven design or at minimum, some tests.  Without tests, it can be very hard to tell if you’re breaking anything when you iterate.  So in a perfect world you would:
   • Write your tests
   • Code until the tests all pass
   • Go back and make it work better
   • Ensure your tests all pass

If you write code and do nothing but refactor and refactor and refactor, but never release it, is it any different than not writing the code at all?  Do you need to make it perfect before you release it to the world (note: this answer varies if you’re writing a blog entry, a web app to count your shoelace collection, or the space shuttle launch sequence)?  Does it have to be 100% optimized before you release it to the world?  Thinking of the last one, I’d say there’s a huge case for writing tests here!

Sometimes though, I think it’s OK to just move on the the next part of the project.  Depending on the goals (ie: is it “real” work, a personal project, a web-app just for learning, etc) it might be better use of your time to move onto the next big part of the project and know that you’ll come back later to make sure that your code is like a rainbow puking unicorn like it should be

Over the Goatee Plateau

… well, the start of grokking it anyway.  Maybe it’s because I’ve finally made it over The Goatee Plateau, or maybe it just sort of clicked and all the bits and pieces that I’ve been reading about since 2004 started coming into play.

More likely though, is I finally got around to stopping worrying about coding and started coding.

I could tell you that going through the excellent Rails Tutorial site by the most awesome Michael Hartl, gave me some confidence or addressed things differently than the thousands of other free Ruby on Rails sites out there.

So here’s the story.  About 3 months ago a web designer I’d worked with before brought me a project.  The project was a relatively simple, but still complex enough to be interesting, site to allow scheduling of referee’s for the local sports division.  Basically there was the need for users to schedule the games, referees to bid on the games they want to ref, and then “assignors” to select the refs to games.  There’s more to it, but that’s enough for here (I’m sure I’m boring you already).

The point of that is that it’s a small project without the need for any really crazy stuff, but not a super simple “we need a weblog in 15 minutes” type requests.  Additionally, there was enough complexity in the project that doing it in my primary language and framework, Perl and HTML::Mason was something that I’d consider actual “work”, and I got the same cold shiver I get when contract clients come to me with “just one quick little change…”.

So I told her that I’d do it, and work on it.  There wasn’t a deadline, or any agreement on money, and I took this as a learning “fun” project with the only thing that I was planning to really get out of it was knowledge.  A couple of days later I set up a Heroku account, and uploaded an initial set of files (the result of a “rails <sitename>” essentially) without any changes or additions.

And it sat there for 2 months.

I was terrified of doing something with it.  As I’ve written before the Ruby on Rails world has changed since 2004.  It used to be a relatively small ecosystem around 2004 when all your code was auto-generated and all you needed to know was the syntax of an “each” loop in Ruby.  Now it’s a huge and complex world of Cucumber tests that write their own tests, NoSQL and Mongo databases, Markdown and Textile, and about a thousand other gems, plugins and libraries that may or may not help you out with whatever it is you’re doing.

Terrified by the choices available maybe?

A couple of weeks later I actually started out doing a bit of work while at a Fraser Valley Ruby Brigade meeting.  Nothing special, just creating some of the models required and trying to get them properly related to each other.  However, after creating the scaffolding I still had that feeling that I really didn’t know what I was up to, I froze up again.  My brain kept on jumping forward into all the “hows”.

“How will I put all this under the old familiar “/admin” setup when all the routes are /referees/ and /fields/ and /games/?”

“If I set up all the smaller models (ie: a list of pay scales) do I need to set up scaffolding for those too? Where do they go?”

“How will I set up the user authentication?  What will I use?  How do I set up my models ahead of time to make sure I don’t shoot myself in the foot for this?”

And it sat there for another month.

Then last week I made a breakthrough of sorts.  I’m not sure if it was going through the Rails Tutorial, or the awesome DataMapper ninja @dkubb giving me the great advice of (paraphrased)

“Just do it in as simple a way as possible, whatever design you come up with will be wrong, so make sure you do the minimum of work to get it working so there’s that less code to change when you come up with a better design.”

Something in there got through and I just started… “getting” it.  I started with the highest level of object I could think of (in this case, the fields that the games would be played on) and created that, then created a main page that would show them.  Then the next level of object (games) and connected them.  Then the next and the next.  So far I’ve really not done a huge amount more than hand writing the scaffolding that rails does for you anyway, but using some of the techniques in the Rails Tutorial I have slowly been iterating my way forward.

One big hole in this project has been testing.  Even though the Rails Tutorial starts almost right away with doing RSpec tests I haven’t put those in.  I also have avoided doing any “real” work on the site, doing other than the scaffolding type stuff.  But still, not having to worry about needing the generators to create views, and knowing what I need to add to a controller to have something start working has been an amazing weight off my shoulders.