I have finally updated the site and intend to post move regularly from here on out. Ok, when I say I updated the site I meant I deleted stupid photos and simplified the design a bit. I am not a designer, I like code not colors.

Many things have changed for me the past couple years; I got married, I've been at a new job for about two and half years now, my army of animals has doubled, and I am a hell of alot better in my work.

I've been lucky enough to attend a couple Elixir Conferences and speak at some local meetups. Elixir has become my latest passion. I've been lucky enough to get a significant amount of Elixir code into production. I hope to get write a post on my learnings soon.

While working on an Ad Server for a current client which I've thoroughly enjoyed writing. I came across some interesting techniques to efficiently query the database using some advanced active record.

These won't be a surprise to the advanced rails developer and I've been using it pretty often in my queries for a while now.

Take the below active record model.

class Campaign < ActiveRecord::Base

has_many :advertisements, dependent: :destroy

has_many :ad_targetings, dependent: :destroy

has_many :ad_targets, through: :ad_targetings

end

class Advertisement < ActiveRecord::Base

belongs_to :campaign

end

The ad class has some additionally associations to keep track of ad stats like click counts and impressions counts.

The client and I decided on having the campaigns be the main targeting object where we can target our users with specific criteria and serve them the appropriate ad.

So normally you could pull all advertisements matching the requested targeting params by searching all active campaigns. The system then would subsequently pool all those campaigns' ads into one array. This would cause two queries or one eager loaded query with some additionaly computation to aggregate the ads.

Nah, that's too much work and pretty inelegant, so allow me to present you with a way to query for advertisements with a where clause on it's association.

This technique is essentially querying through an association and it's pretty flexible. It's all active record syntax and one could even go further with SQL strings.

Two weeks of consecutive articles? Nice, I'm actually sticking with this blog for once.
Now lets get to the business at hand.

I recently setup Devise with Rails 4.0 and I wanted to show the interwebs how I accomplished while using
single table inheritance in my user models. It was surprisingly easier then I thought it would be. Rails 4
has improved their STI support, so a good amount of custom code needed is not necessary anymore.

Gemfile

We are using the Rails 4 branch from the Devise repo and the protected attributes gem to avoid
overriding the default Devise controllers. Of course normally this is not a dangerous thing to do
but I preferred to not have to write a bunch of custom routes and keep my routes simpler. Also, we can
still use the strong parameters with our other models which I'm actually liking, only our User model will
have some attr_accessible code. But, if you so choose to not use protected attributes gem, I will show you
you how to override the necessary Devise functions but most likely they will have updated their code to not use
protected attributes.

Routes

This is the most important part and using the default Devise helpers we can accomplish what we want. Note how I've namespaced the
user scopes. Feel free to customize to your needs, but you should have something similar to the below.

Of course you do not need to do namespace your user subclasses, it just makes more sense to me and gives me a good
base to keep my views more OO and organized down the road.

Now in my situation, only sellers and buyers will be able to register but all of our subclasses need links to be generated
to the Devise controllers but we want to keep the session pass scoped to Users only and not generate routes for a users registrations
In the past to customize the session paths "login, logout etc" you'd pass a block to the devisefor helper but this
practice has been depreciated so if you still want to override those paths, you must use the devisescope helper.

Now, with our routes in place and our models setup. We're actually good, just need those default devise views

rails g devise:views

Caveat, some of the links in the views/devise/shared/_links.erb partial will throw exceptions so you'll either want to customize them or remove

Helpers

Devise gives you some default helpers to use in your controllers and views, usersignedin?, currentuser, and even currentadmin but current admin requires
the base devise db model to actually be a Admin base so we'll want to override this becuase of our STI situation.

Of course, I'll eventually want to move this into a controller concern to clean up the application controller.
And notice how I'm using different "authenticateuser!" methods, I find it convenient to scope buy the subclasses in my controllers.
And not how I've overridden the devise aftersignoutfor(resource)

Departing tidbits

The last techinique I wanted to show you is what I promised earlier where we wouldn't use the protected_attributes gem.
Just override the devise/registrations and devise/passwords controller and add the below method to it.

​Single Table Inheritance in Active Record is something to not be afraid of. Let me show you one of the ways it completely makes since. Throw in some Postgresql Hstore magic and you have a flexible and fairly straightforward solution to a couple different problems.

I manage a team of two. As lead developer, I am responsible for making important design decisions. My teamates are large working on the frontend of our Rails app and they're newcomers to the wonderful world of Rails. So not only do I manage, I mentor. It has been a learning experience for me as well as for them.

I'm not always right so when I suggest a particular gem or advise a particular way of writing a particular feature, most of the time I'm correct but there will also be times I'm completely wrong. I'll find myself checking out there work and coming up against the walls they previously wrestled with and also finding myself scratching my head. I swallow my pride, admit I was wrong and move on. We'll find a solution as a time and implement in a timely manner.

I wanted to make this point, these are lessons, valuable lessons. We must learn from these lessons and just attempt to not repeat them in the future. All I can do as a mentor and show them the Rails way, provide good coding styles, and impart proper OO design.

I intend to be a stronger team leader/manager, so when I make mistakes and learn from them, my team must also learn from them.

The upcoming release of iOS6 will feature an app by Apple called Passbook. It will be a stepping stone to Apples entrance into the Digital Wallet arena. A digital wallet allows users to make electronic commerce transactions quickly and securely. There are already many players in the mobile payment space: Square, Sprint, Visa, Mastercard, Amazon, AT&T, Paypal etc.. They all are developing or have developed diverse platforms utilizing different technologies.

Passbook

Out of the gate Passbook supports the following:

Boarding Passes

Gift Cards

Coupons

Event Tickets

What Passbook will offer:

Groupon and Living Social vouchers

Possible credit cards aka Mobile payments

Passbook in the words of Apple:

Your boarding passes, movie tickets, retail coupons, loyalty cards, and more are now all in one place. With Passbook, you can scan your iPhone or iPod touch to check in for a flight, get into a movie, and redeem a coupon. You can also see when your coupons expire, where your concert seats are, and the balance left on that all-important coffee bar card. Wake your iPhone or iPod touch, and passes appear on your Lock screen at the appropriate time and place — like when you reach the airport or walk into the store to redeem your gift card or coupon. And if your gate changes after you’ve checked in for your flight, Passbook will even alert you to make sure you’re not relaxing in the wrong terminal.

Apple plays the long game. It does not release game changing apps that have an affect right off the bat. They improve on the idea through timely updates that before anyone knew it, the intended consequence come to light to the public. I believe Passport is one of those ideas by Apple. They already have a robust virtual ecosystem in the App Store. Adding an iTunes section for Passport makes perfect sense. Record companies will be able to sell tickets through the iTunes Store, completely bypassing Ticketmaster and other venues. The complete cutting out of those middlemen will reduce scalping, reduce ticket prices without hurting the artists. The business model may be tricky and negotiations will still be ongoing.

I envisage a time where I can buy my movie tickets, my Starbucks coffee, redeem my gift cards to various retailers, my Living Social vouchers, and those Buddy Guy tickets in November; all through the Apple iTunes Store.