Tips

My Process for Writing a Talk

There’s a ton of blog posts out there with advice on how to write talks. They all discuss the “right way”, but in reality I don’t think anyone follows a process prescribed by someone else.

I’m a very visual person and in a way I write talks backwards. “The right way” would be to write copy and then build the slides around it. I shouldn’t even be opening Keynote until I have solid, well-articulated copy. But that’s not how I’ve been writing talks.

I’m definitely not recommending you follow my way of doing things, but I thought it would be fun to share my process. I’ve developed approximately 6 talks between meetups and conferences. I put a lot of time and effort into each one. My How to Performance talk was probably 100-120+ hours depending on if you count revisions and practice I did before each conference.

Here’s my process:

1. Talk to anyone who will listen about something I’m passionate about or working on recently. The talk I’m currently writing is about Security. I’ve ranted and explained all sort of things I believe about security and patching applications to anyone who will listen; my dog, my husband, my friends and coworkers. If I keep talking about it enough, I know I care about it enough to turn it into a talk.

2. Collect ideas in a Google doc so I can access the file anywhere.

3. Come up with a title (see I told you this was backwards because this is “supposed to” be after an abstract)

4. Write an abstract.

   • Write something, anything down that resembles a beginning, middle and end of an abstract

   • Show it to my husband who tells me how to write a better one

   • State that I can’t do this, I don’t know how to do this

   • Go to the gym and work out my frustration

   • Come back and bang out a kick-ass abstract

5. Write an outline. This is where it starts to get weird.

6. Open Keynote and pick colors. Colors are very important to me. I was a photography major and have a design and art background. If the colors don’t feel right I can’t write the talk.

7. Collect memes and gifs to help express myself.

8. Build out the middle slides; the meat. This is generally where I start adding all the gifs I’ve saved over the past couple months that I think would go great with sentiments I have in the talk.

9. Freak out that this talk isn’t going well and it will never be good. I’ve given 3 well liked talks at 8 conferences and I still believe they were a one-hit wonder and no one will like any future talks. This is something I deal with every time, and it’s hard. It’s difficult to tell yourself you’re going to be fine. That’s why it’s good to have a great support system of family and friends who will help pull your head out of your ass so you can keep working.

10. Start writing copy for the beginning slides I never added. Add slides to fill in the opening of the talk as I write them.

11. Write the copy for the ending slides I never added. Add slides to fill in the end of the talk as I write them.

12. Go back to the middle slides and write the copy for those adding, removing, and reordering slides as necessary. Once I’m satisfied the talk is “written” I go back and edit copy. Written to me just means I could go give this talk as is and it would be complete, but confusing. It’s not perfect but all my main points are in there.

13. Give talk at a local meetup.

14. Make changes based on the meetup feedback.

15. Practice. Edit. Practice. Every night for 2-3 weeks leading up to the conference.

16. Give talk at a conference.

17. Make changes based on things I felt were confusing and based on questions/feedback I get.

18. Repeat 15-17 until I retire the talk.

This process, while convoluted at points, is my process. This works for me. Don’t let anyone tell you you’re doing it wrong. It’s your talk. If you a) get up and actually do it or b) people find your talk interesting, then you were successful. Find what works for you and what gets you up there on that stage. That’s all the matters.

I’m giving talks at 4 conferences so far this year. Mountain West Ruby Conference in March, Twilio’s SignalConf in May, Brighton Ruby Conference in July, and AbstractionsConf in August. You can always find what conferences I’ll be at on my speaking page.

Getting Your Local Environment Setup to Contribute to Rails

At RailsConf I’ll be leading a workshop on contributing to Ruby on Rails called “Breaking Down the Barrier: Demystifying Contributing to Rails”. My goal is to help you be confident in your ability to contribute to Rails. I’ll be focusing on contributing guidelines, advanced git commands, and traversing unfamiliar source code. I’ve allotted 90 minutes for the workshop so in order for you to get the most out of it you should have your system ready. In this post I’m going to go over the basics of getting set up.

Technically, the easiest way to get Rails running locally is to use the supplied VM. I prefer to have it running on my local machine, but if you’re using Windows I highly recommend using the VM. Although the VM is referred to the “easy way”, you likely already have 50% of the things you need installed on your system already if you’re actively developing Rails applications. If you do decide to use the VM you can skip these instructions. Please contact me on eileencodes to let me know if the VM directions are wrong. Or better yet, if you figure it out send a pull request!

Let’s get started with the basics of getting set up!

Ruby Manager

When working with Rails it’s likely you’ll be using a different Ruby version than you use in your production applications. It’s best to use Rails master with the most up-to-date version of Ruby. Currently, you can’t use Rails master / future Rails 5 without Ruby 2.2.2. You probably already have a way to have multiple rubies installed on your machine with either rbenv, rvm or chruby.

I personally use rbenv but I’ve used rvm in the past and hear good things about chruby. It really doesn’t matter which one you use as long as you can have multiple rubies installed on your machine.

Once you have that set up, install Ruby 2.2.1 2.2.2 (2.2.1 had a security vulnerability). Don’t forget if you have a new version of Ruby you’ll need to install bundler before you run bundle install on the Rails repo.

Fork & Clone Rails

Now we’ll get the Rails source code set up. First go to [github.com/rails/rails][rails-repo]{:target=”_blank”} and click “fork”. Some developers prefer to clone the main Rails repo and set up their fork as an upstream, but unless you have push rights to Rails (a commit bit) I don’t think this really makes sense. In my opinion having origin set as your repo works best so this guide is going to show you my preferred method.

Checkout your version of Rails to your local machine:

$ git clone git@github.com/your-fork/rails.git

You’ll need to get Rails master main repo as an upstream to your Rails. To do this simply run:

$ git remote add upstream https://github.com/rails/rails.git

Anytime you want to pull changes from Rails master into your master do:

$ git pull --rebase upstream master
$ git push origin master

Here you are pushing to your origin so your remote origin is always up-to-date with your master branch. Don’t work on your master branch and send PR’s from there. Always create a new branch. That way you can be working on multiple patches and your master is always clean and ready to checkout a new branch from. Pushing to your origin master also makes it easy to reset any of your branches to master without having to re-pull changes from upstream Rails.

Don’t forget to add a .ruby-version file to your Rails repo, but be sure not to check this in. I have a .gitignore_global file that sits in my home directory and ignores all .ruby-version files. Then you should run bundle install.

Databases

Ok now that you’ve got the Ruby and Rails source, you’ll need to get a few more things installed before you can start running Rails tests. And the most important of those things is databases!

It’s not really a requirement that you have ALL the databases installed but it’s a good idea to have the default databases that the Active Record supports; SQLite3, MySQL, and PostgreSQL. This will help you test the main adapters that are supported in Rails. It’s also a good idea if you’re working on any SQL specific parts of Active Record; you want to be sure you aren’t negatively changing the behavior of those other databases.

How you install databases is up to you. As a OS X user I install them with homebrew and follow the instructions output after installation. Remembering all the start/stop commands for databases is a pain though so I use LaunchRocket to control this. It’s a OS X preference pane to manage databases installed with homebrew. Additionally, you’ll need memcached for some ActionDispatch and ActionController tests.

Once you have the necessary databases installed you’ll need to create the databases and users required by the Rails tests.

MySQL

First create the users

$ mysql -uroot -p

mysql> CREATE USER 'rails'@'localhost';
mysql> GRANT ALL PRIVILEGES ON activerecord_unittest.*
       to 'rails'@'localhost';
mysql> GRANT ALL PRIVILEGES ON activerecord_unittest2.*
       to 'rails'@'localhost';
mysql> GRANT ALL PRIVILEGES ON inexistent_activerecord_unittest.*
       to 'rails'@'localhost';

Then create the databases

$ cd activerecord
$ bundle exec rake db:mysql:build

PostgreSQL

If you’re a Linux user create the user by running:

$ sudo -u postgres createuser --superuser $USER

If you’re an OS X user run:

$ createuser --superuser $USER

And then create the databases:

$ cd activerecord
$ bundle exec rake db:postgresql:build

Creating and Destroying

It’s also possible to create both MySQL and PostgresSQL databases at the same time by running:

$ cd activerecord
$ bundle exec rake db:create

And you can destroy the databases and start over with:

$ cd activerecord
$ bundle exec rake db:drop

Running the Tests

Now that you have Ruby, the Rails source code, and the databases installed it’s time to run the tests. Now don’t just run rake test in the Rails root directory because you will be there all day waiting for railties tests to finish. Simply cd into the library you want to test and run:

$ rake test

To run Active Record tests, be sure to include the database adapter you want to test or else sqlite3, mysql, mysql2, and postgresql adapter tests will all run. To run tests for specific adapters do the following:

$ bundle exec rake test:sqlite3
$ bundle exec rake test:mysql
$ bundle exec rake test:mysql2
$ bundle exec rake test:postgresql

And don’t forget all these commands are available if you run rake -T in the directory you’re in.

See You at the Workshop

I’d tell you more about contributing to Rails but then I would have nothing to talk about at the workshop! I know it will be a lot of fun and you’ll learn tons. To read more about my workshop go to the RailsConf website.

If you have any issues at all getting set up ping me on twitter at eileencodes and I’ll do my best to point you in the right direction.

Upgrading to Mavericks: When Everything Goes Horribly Wrong

I'm one of those curmudgeons that if it's not broken I don't want to fix it. I felt this way with upgrading from whatever Mac cat I was on to Mavericks and had put it off for a longggg time. Everyone said it would be easy and I should just do it. And I wondered if I was being lazy not going for it, so this weekend I took the plunge, which took several hours of convincing myself. The worst part was I started way too late, with a short 2-3 hour window before friends came over for dinner. The smart thing would have been to upgrade on Saturday morning.

I'm glad I put it off until I had real time to spend on it because it ended up not being smooth at all. Sure, I had a backup but when you're done upgrading and knee deep in fixing things, going backwards isn't too desirable. You have to make a choice to continue forging ahead or to turn back. When you're in the dark woods of an upgrade that went horribly wrong there's no way to know which path will be faster, so I chose to forge ahead.

What was broken?

Generally Mac applications worked fine, but I had to manually update and install command line tools for Xcode. This was kind of annoying to me because I feel like it should just be part of the upgrade. If a user has xcode and command line tools installed just update that along with everything else. I'm assuming if you're not a programmer your Mac upgrade probably went better than mine.

RVM and anything installed with homebrew was completely broken. It couldn't find any of those libraries or programs. I removed and reinstalled everything in homebrew; ack, mysql, postgresl, openssl, readline, etc. The biggest thing was after reinstalling these was the mysql and mysql2 gems needed to be uninstalled and rebundled because they were setup to use a different version of mysql.

But as said many times before "always google first" - but make sure you're googling for the right thing. Thinking my problem was with rvm I was googling the errors I was geting and none of those posts said to fix homebrew first. Unfortunately it wasn't until I was going rogue uninstalling and reinstalling everything that I realized that most of my issues were with homebrew and could have been fixed simply by following this post.

So if you have errors like "Libary not loaded: /path/to/openssl", "Libary not loaded: /path/to/mysql" etc, just follow the brew instructions in that post and your upgrade will probably go better than mine. If that doesn't fix it my recommendation would be to reinstall the libraries it's complaining about until it works. I also found that some rubies I needed to run rvm reinstall [ruby-version-number]

So if you do upgrade first backup, upgrade and fix homebrew before panicking. There are a couple nice things about Mavericks but so far I'm not impressed enough to be ok with fixing my dev environments.

Oddly no one I knew seemed to have these homebrew problems, so it could be some setting on my Mac? Hopefully though this will help someone else if they have issues with upgrading to Mavericks.

Just Use `ack`

I spent a good portion of yesterday obsessing over my grep colors. They worked fine on my VM (Ubuntu) but not on my mac. I then figured out that mac is FreeBSD and Linux grep is GNU. So the export GREP_COLORS='1;32' just isn't going to work.

I then spent too much time trying to get that to work when all the Stackoverflow sources said just use ack. So I gave in and installed it because I was tired of doing it "the hard way".

It's amazing. I know most of you probably already use ack. If you don't you are "doing it wrong" as I have been for some time. Now stop wasting time reading this and go download it. 

Installation instructions here.

Colors and line numbers are on by default! Yay! To change the colors simple add this to your .bash_profile or whatever your preference:

alias ack='ack --color-filename="red bold" --color-match="yellow bold" --color-lineno=white'

You're welcome.

Nifty Methods: cycle(first_value, *values)

Recently I was working on an app and needed to "cycle" through some values. Previously, the code was using each_with_index and using that index to figure out where the "odd" or "even" class was applied to the table rows. Since I needed to change the code to use map I could no longer use each_with_index effectively.

First my thinking was to use modulo to loop through and add the classes, but that seemed to be complete overkill for my situation.

I then turned to google to find something simpler. It seems Rails already has a dead simple solution. It amazes me every time I find something that I don't feel is necessary to write from scratch already in existence.

The method is cycle(first_value, *values). This can be used for many things, but the most obvious is cycling through "even" and "odd" classes, but can also be used to more advanced arrays. The Rails API uses cycling through colors as an example. The method also can accept a Hash to create a named cycle.

If you're interested in reading more about this nifty little method, you can find more details in the Rails API.

The Pros of Working from Home: My First Two Weeks in the "New" Office

I recently changed jobs and now work as a Senior Developer at PhishMe! I love my new job, coworkers and my new "office". Being that the company is based in Virginia and I'm not, I now work from home. When I tell people that I almost always get "Oh, I could never do that...". I used to think the same thing, but now I know (at least for the type of person I am) that working from home is AWESOME.

I don't think working from home is for everyone. You have to make a great environment for yourself to work in and you have to be a self-starter. Understanding how you work and what gets in your way the most is important. For me, human's are a major distraction, I can't concentrate if there are people around me talking or moving. Sense wise, I'm extremely sensitive to my surroundings and if I don't want music playing or people talking it can be detrimental to productivity for me; and I'm completely aware that this is my own neuroticism.

So by this point you're probably wondering what I like most about working from home?

Ability to control my environment

The number one thing I enjoy is the ability to control my environment. I cannot stress how amazing this makes my day. I get to control the temperature in my home office. If it's cold, I turn on the space heater, if I'm hot, I open a window. I can be as cold or as hot as I desire, and changing that quickly is not difficult. There is no longer a "consensus" on temperature required.

Having my own space

This office is mine. I own my space and I'm CEO of my life. In the type of work environments we are moving towards there is very little room for "your own time" or space. I found that in a big office where all the space was shared, that it was hard for me to get "in the zone". I couldn't focus on one problem because I was always being asked (not always literally) to focus on something else whether it be talking, or a meeting, or a new project, or a maintenance task. I could never just mentally hone in on my work.

Food

Oh my, all I keep thinking is that "sad sandwiches" are out of my life. If you don't know what a sad sandwich is, you are very very lucky. I can have hot food whenever I want. For breakfast? Yes. For lunch? Yes. For snack? Yes. No more wondering if someone will steal your fancy yogurt, or thinking "Ugg, I guess I'll use the microwave to avoid eating a sad sandwich". I could, if I wanted to spend my entire lunch break making food and eat at my desk, but that lunch will be so much tastier than re-heated leftovers from the night before that just don't taste right microwaved. If you're thinking "Wow, this lady is picky about food preparation" - yes, yes I am.

Flexibility

This might seem odd, but working in an office with mostly males (I'm female) has at times made me self-conscious. Some days your legs are just sooo tight you want to do some stretches at your desk, but bending over in the middle of the office just doesn't seem ideal. Well, now I can do that and there's no one to make me feel weird about it.

Lack of Morning/Evening Commute

No more travel. I never really commuted that far, ~30 min each way, but that's an entire hour of my day, and hour I could never hope to get back. My new commute is short and sweet. The best part is no one can get in my way. I was always dealing with slow drivers or bad drivers causing unnecessary frustrations.

So there you have it, my reasons why working at home is awesome. If you're thinking "could I work at home?" I would make a list of pros and cons. Also, very important is spending the money to make sure your home office is perfect. I made the darkest least favorite room in our house into a lovely, bright, homey room that I want to actually spend time in. It's very comfortable and I love it.

Now I've Got Pretty Permalinks and Much More

Note: This blog post referred to an older version of this blog that I had built from scratch. I've attempted to update links so they don't 404, but know that this post is not currently accurate.

I'm off to a pretty good start with my yearly goals. It may not look like it but I've made a lot of changes under the hood to this blog. I was finding my ability to find myself on google pretty low so I added a sitemap — and it's not just any sitemap, it auto-updates using sweepers. In the next post I'll go over how to build the sitemap specifically.

A couple other new features are "pretty permalinks" and an RSS Feed. For the permalinks I used the Stringex gem. The gem allows you to more easily control your permalinks and comes with a nifty little method that allows you to create the URL's for already existing posts. I then made sure I added rewrite rules to my nginx config so that the old /posts/1 urls still functioned. Nginx rewrite rules are a little different from Apache as you can see in my exmaple below:

rewrite ^/posts/1(/)?$ /posts/hello-world permanent;

Lastly, I updated my 404, 422, and 500 pages to actually look like my site. Yipee!. I should have done that earlier, but when I built eileenbuildswithrails.com I wanted to get it live before the New Year.

Next set of changes will involve adding pages to the cms, including a contact form, ability to add images, and perhaps comments. Thanks for reading!

:has_many Relationships in ActiveAdmin

When I began using ActiveAdmin I discovered that there is not a lot of documentation on advanced usage such as displaying the :has_many relationships on the index and show page in the admin of the posts. I wanted to make it easy to add categories to posts and to know how posts were categorized easily.

Once the Category and Post models are created a join model also needs to exist, in this case Categorization. This part is the same as any other :has_many, the hard part is display in the admin.

Go into the admin view for Post and add the following (other fields removed for easy viewing):

index do
  column :title, :sortable => :title do |post|
    link_to post.title, [:edit_admin, post]
  end
  
  column :categories do |post|
    table_for post.categories.order('title ASC') do
      column do |category|
        link_to category.title, [ :admin, category ]
      end
    end
  end
  default_actions
end

show do
  attributes_table do
    row :title
    row :content
    table_for post.categories.order('title ASC') do
      column "Categories" do |category|
        link_to category.title, [ :admin, category ]
      end
    end
  end
end

form do |f|
  f.inputs "Add/Edit Post" do
    f.input :title
    f.input :content
    f.input :categories, :as => :check_boxes
  end
  f.buttons
end

As you can see inside the tables creating a special inner table is required for best display. I add the link to the category edit in so it's easy to edit/view the category from the posts table.

To add checkboxes for category select it's as simple as adding f.input :categories, :as => :check_boxes to your form view.

Want to figure out how to set up active admin? Read my "Lots of Love for ActiveAdmin" post. If you have questions, comment on the gist on github or find me on twitter.

ActiveAdmin is a really great simple way to implement an admin for a simple website or blog.

Honeypot for Rails Email Form

While working on my companies new website I realized that our contact form didn't have any spam protection and would become a favorite of bots not long after launch so I decided to add a honeypot.

If you're not familiar a honeypot is a hidden form that users can't see, but because bots don't read CSS they fill it in. If the form is filled in it automatically fails. This is a better alternative to the captcha because it doesn't require your users to type out a ridiculously illegible code (which from experience, i can tell you gets frustrating when you've gotten it wrong 60000 times).

I searched through a few gems and after being frustrated with the outcome decided to just do it myself because really it's just a few fields and the form is ajaxed and the gems would send a 200 response essentially removing the form, which was no my intention.

Open your form view and add a field for the honeypot. Be sure to add a label explaining it is a honeypot to ensure accessibility for screen readers and instructing users to not fill in the field.

<div class="field sweet_honey_for_bots">
  <%= label_tag :sweet_honey, "This is a honeypot, if you see this you're CSS is turned off or you're a bot. If you're not a bot don't fill it in." %>
  <%= text_field_tag :sweet_honey %>
</div>

Then go to your model and make your field accessible; attr_accessible :sweet_honey

One last quick step is to instruct your form what to do on save. You can have it simply fail with no error but that isn't accessible plus if anyone does fill it in, you might want to give a fun little message for them. I have my form rendering a partial because of the ajax-iness, plus I don't want the form to disappear just in case it's not a bot.

if params[:sweet_honey].present?
    format.html { render :partial => "emails/email_bot", :layout => false }
elsif @email.save
    ...
else
    ...
end

This is super simple implementation of a honeypot. I figured why make it more complicated when I just want to prevent send?

Lots of Love for ActiveAdmin

I have been so heavily immersed in work projects that I haven't had the time to write posts about rails - or do much of anything else.

Recently, I have been using the ActiveAdmin gem for the websites I've been building with rails. We are rebuilding our company website with rails and an ActiveAdmin backend. ActiveAdmin is awesome, the documentation could use a little love, but other than that I have no complaints about the system. I do believe everyone should build a rails administration system from scratch at least once to ensure understanding of how authentication works.

I'm going to go over some of the basics of getting up and running with ActiveAdmin and then in later posts will go into more detailed instructions on more complicated things you may want the admin to do like model relationships and integration with paperclip.

Installation

To get started add activeadmin and meta_search to your Gemfile. Bundle install and begin development! Activate the default admin user model by generating the resource: rails generate active_admin:resource AdminUser. The default login information is admin@example.com/password.

Beginning Development

First, the admin user model must be configured. An important thing to note on installation is that all the fields for the user are visible including encrypted_password, reset_password_token, etc and if you try to update/add a user before changing the available fields you will get a "mass assignment" error. Find the admin_users.rb in app > admin and add the following:

ActiveAdmin.register AdminUser do
  index do
    column :id
    column :email
    column :full_name do |field|
      "#{field.first_name} #{field.last_name}"
    end
    column :last_sign_in_at
    default_actions
  end

  show do
    attributes_table do
      row :id
      row :full_name do |field|
        "#{field.first_name} #{field.last_name}"
      end
      row :email
      row :last_sign_in_at
      row :sign_in_count
    end
  end

  form do |f|
    f.inputs "Edit User" do
      f.input :first_name
      f.input :last_name
      f.input :email
      f.input :password
      f.input :password_confirmation
    end
    f.buttons
  end

  filter :id
  filter :email
end

You'll notice I've added extra fields to the db, namely a first_name and last_name to create full_name. This file changes the main views in the administration interface — the index view (table of users), the show view (each user's settings), and the form (updating/adding users to the admin panel).

Be sure to update your model to include validations, messages and relationships.

Adding new models is as simple as generating a model and a resource. If you want to create a model that isn't updated through the ActiveAdmin interface, create a has_many join table model (ex, categorizations), but leave out the resource generation.

And that's all you need to get started, very simple gem to use. Although I could get a lot more in-depth about the features of ActiveAdmin I'm going to pause here. I encourage you to play around with it, the ease of use makes development even more fun. It's great to not have to worry about designing your admin interface for fast development.

My First Week with a Sit-Stand Desk

Although this pos is not related to Rails I thought it as valid becasue it's about the culture of technology companies and keeping that culture from being stale.

And sitting was getting stale. In fact, sitting had been stale for me for quite awhile because for a year and a half I have had on and off excurciating back pain that leads to migraine style headaches ad massive amounts of crankiness, not to mention the productivity you lose when all you can think about is the amount of pain you're in.

So this week I started with an ergotron sit-stand style desk. I would post a picture but I have yet to install paperclip on my blog for adding posts (I really should get to that).

The nice thing about this style desk is it can move up and down to be at the perfect height for your hands or so if you're tired of standing you can sit easily without needing to purchase a higher chair.

The company has many different styles from dual monitor to monitor and laptop, something for everyone. It attaches to an existing desk by a clamp which worked really well for my office because we have built in work stations that came with the office. It didn't require any decontruction of the stations.

I was surprised to find that I could stand almost all day. Of course I get fidgetty, but I was like that when I was sitting too. I don't know if I can say yet that I think better, but I am definitely less tired and in less pain. Good shoes are really important becasue my heels start to hurt if I'm not wearing supporive and comfortable ones. I encourage you to try it out if you can. I'll most iikely be purchasing a standing desk mat for computing barefoot so my heels don't hurt as much.

There's More to User Experience Than Ease of Use: Lessons in Not Scaring Your Customers

This post is not really going to be Rails related. But everything in a Rails blog doesn't need to be about Rails, or Ruby, or coding at all.

I feel like Rails is an experience, in not being frustrated with everything and it's easier to map out an application. The things that get in the way of building something awesome, the time consuming, awful things like join queries and pluralization are done for you. You can focus on your application and it's beauty and structure.

Well, user experience is also an experience and I hate that it's so often that a website has me banging my head against a wall. Recently, I logged on the Sallie Mae website to check something with my student loan. Being that I have it set for auto-debit and that I was logging in on a weekend I was met with a front page telling me I was delinquent on my loan.

Now people who know me will know my reaction without telling you. I literally flipped a shit. Thinking my bank account information was lost or some other awful scenario (was my bank account hacked and emptied?? no...it wasn't phew) I searched through my account for an answer when the answer occurred to me.

Sallie Mae does not have a failsafe in place so that when you have auto-debit activated and the date of debit falls on the weekend it doesn't "figure it out" it instead tells you you didn't pay and that you better do it now.

Awesome. Please when building an application make sure you put in if else statements that check for things like weekends, and auto-debit. It will make your customers happy. No one wants a mini heart attack on Sunday evening, to log in the next day and see all is well.

User experience is more than making a site easy to use, and beautiful (both which Sallie Mae fail at). It's also about not scaring the crap out of your clients and consumers — or accepting 76 early acceptance students accidentally (I'm looking at you Vassar). When desiging a web application consider all the horrible things that can go wrong for the user, not just you the developer and put failsafes in place to prevent those things. You will have happier clients that will keep coming back again and again.

Frustration is never good for business.

The Footnotes Plugin for Textmate

Around the beginning of the year I decided to watch every Railscast tutorial. I know what you're thinking — that this was a "New Year's Resolution". Well that's simply not true. It just appears to be one. I resolved to do that way before the New Year, it just so happened that on January 3rd is when I had time to start.

Well some people have said, why watch every one? They are old and from 2007 and some aren't relevant anymore. That may be true, but at EMN we have some legacy Rails sites that I didn't build but might have to one day fix, and it helps to know what has changed from Rails 2 to Rails 3, etc.

I've also learned some really great things and tips. One in particular is the footnote plugin for textmate which links the error messages in Rails to where they appear in your code. In your footer it also describes the SQl calls & queries, and analyzes the speed, shows the CSS and HTML and everything you might want to inspect for that code. The video that describes it is "The Stack Trace" and although the method for installing the plugin shown in the video no longer works you can download it from github and follow the installation instructions there. It needs to be installed for each app and added to your .gitignore because this plugin should only be used in development mode.

Happy coding!