Posts

My latest iOS application, Heart Quest, uses Facebook authentication and Parse for the back end. I ran into some challenges getting the two to work together but I am pleased with how my current implementation functions. I’d like to share that implementation here to help anyone who may be developing an app using Facebook authentication with their Parse apps.

NOTE: This will most likely be my only blog post related to Parse due to the service shutting down later this year.I have begun using Firebase as an alternative so look forward to some Firebase tutorials in the near future!

If you still need to setup the Facebook SDK with your Parse app you can use the excellent guide over at Ray Wenderlich’s website. If you already have the Facebook SDK installed please continue with this tutorial.

logInWithReadPermissions is where you set the type of permissions you would like to request from your users. In the above example we are only asking the user for their basic profile information (name and profile picture). If you wanted to request additional permissions, such as the user’s Facebook likes, you would add that to the permissions array:

logInWithReadPermissions(["public_profile","user_likes"],

If there are no errors with logging in you’ll then want to check for any valid Facebook access tokens:

if let accessToken: FBSDKAccessToken = FBSDKAccessToken.currentAccessToken() {
PFFacebookUtils.logInInBackgroundWithAccessToken(result.token, block: {
(user: PFUser?, error: NSError?) -> Void in
if user!.isNew {
//segue to Sign Up form for a new user
} else {
//segue to first view for logged in users
}
if error != nil {
print("Uh oh. There was an error logging in.")

Use the .isNew method to check if that user has ever signed in to your app. This allows you to send new users to a separate Sign Up form so that you can save their user information in your database. If .isNew is false, use the else statement to send the logged-in user to your app.

If there is an error with the access token (error != nil), the best way to handle it is to create a new token and retry the login process:

I wrote a tutorial last year that explained how to customize the Mailboxer Ruby gem and it was well-received. Many people requested source code so that they could debug issues. I unfortunately did not have the availability to provide the source code at the time. However, I am very happy to announce that an open source application is currently available on Github and it is completely free to use. A live demo of the app is also available on Heroku. I hope this helps anyone that is struggling to get mailboxer up and running in their Rails app! As always, feel free to ask questions if you run into issues.

Updated 3/1/2015: I was unable to gain traction for this idea so I am shelving this project. I may revisit the idea at a later time.

My project, Workula, has quietly launched today. As much as I wanted to continue to polish the code and add new features it needed to be launched. I am in need of feedback and this is the best way to do it.

So what is Workula? Workula is a website that allows users to share work experience. We’re changing the definition of work experience because it puts college students and the unemployed at a severe disadvantage. Work experience is currently defined as being employed by a company for a certain amount of time. We define work experience as “work”. With Workula, work experience is broken down into smaller updates we call WorkBlocks. A WorkBlock can represent a status update, a comment on other work, new work submissions, and contributions to other work. We feel that breaking down work experience like this will encourage people that don’t have formal work experience to enhance their set of skills and document each step of the way.

I invite you all to sign up for a free account today to begin sharing your work experience:

Update 3/1/2015: This tutorial has been updated for Rails 4.2 and Mailboxer 0.12. I also created a demo application that can be found on Github. A live demo of the app is also available on Heroku.

The Mailboxer Ruby gem is a robust messaging system that is extremely easy to implement in any Rails app. There are some good tutorials out there that explain how to quickly get it up and running but I saw many questions that asked how to customize the inbox. In this blog post I will explain how to set up the Mailboxer gem and customize the views to contain the following:

Inbox with Sender, Subject, Date, and link to move to Trash

Trash with the same information as Inbox as well as a button to delete all conversations in Trash and a button to move a conversation back to the Inbox

Conversation view page showing all associated messages and a reply form

You’ll see the words “conversation” and “message” used throughout this blog post. In Mailboxer a conversation is simply a group of messages. Our Inbox and Trash pages will contain a table of conversations. Clicking on a conversation will open all of the messages associated with that conversation.

Note: I will be using the current_user method to refer to the currently logged in user. This method is supplied by the Devise gem. If you are not using Devise to handle user authentication be sure to replace this method with your own.

Much of this code for the Conversations controller was provided by RKushnir’s Mailboxer sample app on Github. You can see the full controller code here (since this is a private messaging system between two users, the create action in the linked controller is not needed).

Installation

Add the following line to your Gemfile:

gem &quot;mailboxer&quot;

Then run:

bundle update

Next, run the install script. This script will automatically create the migrations that are required for Mailboxer to run:

rails g mailboxer:install

Migrate your database once the installation is complete:

rake db:migrate

Prepare the models

Mailboxer can be used on any model but in this example we’ll prepare our User model to use Mailboxer. Add the following line to your User model:

User &gt; ActiveRecord::Base
acts_as_messageable
end

Basic Mailboxer view

To create some test messages use the following method in the Rails console or set up a form in a view (replace “recipient_user_object” with a real User object from your app):

Create a trash_folder action in your Conversations controller and add an instance variable which will contain all of the user’s messages in the Trash folder:

def trashbin
@trash ||= current_user.mailbox.trash.all
end
end

The above actions will handle our Inbox and Trash pages. However, we’ll also need to add actions for the Trash and Untrash actions. We will be adding a link on the Inbox page to allow the user to send a conversation to the Trash folder. We’ll also add an “Untrash” link on the Trash page to send a conversation back to the Inbox page. To do this, create the trash and untrash actions in the Conversations controller:

Mailboxer keeps track of the participants in a conversation. In our case, the only participants are the sender and the recipient. To show the sender of a message, loop through all of the participants and only show participants except for current_user:

To show the date it was sent, you can use conversation.created_at. In the code below I’ll use update_at since conversations may last longer than a day. I’ll also use strftime to format the date into the “Sun, 01/01/2014 12:00 PM” format:

In the next section we’ll need to setup the routes so that the Trash links will work correctly. Before we move on to the routes we’ll need to customize the Trash page. The Trash page is going to be the same as above except for two things:

1. When looping through the participants to display the sender, change the first line to this:

&lt;% @trash.each do |conversation| %&gt;

2. Change the Trash link to an “untrash” link. Clicking on this link will send the conversation back to the Inbox:

I recently deployed a Rails application to a cloud application platform in order to gather some feedback. The application ran just fine on my development machine and I couldn’t wait to push it to a server so other people can test it. I had this preconceived notion that my app would magically appear on the public internet with the push of a button (you would think I knew better by now). The process took a few sleepless nights to complete. This blog post will explain the issues I encountered with the deployment and how I resolved them.

My first thought was to deploy my app to Heroku since deploying an app to Heroku was one of the first things I had learned when reading through the popular Rails Tutorial. Once I had pushed my app to Heroku I immediately noticed that something went terribly wrong. My app was not loading CSS! The app’s logo loaded just fine but there was absolutely no formatting. Just white background with black text in a single column. Thinking that there must have been an incompatibility issue with my app and Heroku I decided to try deploying to a Digital Ocean server using the Cloud66 platform. Same result. I then knew something was wrong with my configuration.

After doing some basic research I discovered that many other people run into this issue as well. I saw many different solutions that, at the time, I knew very little about. Before doing any research at all I highly recommend reading the Ruby on Rails documentation on the asset pipeline. Had I read that sooner I think I would have came to a solution in a shorter amount of time and with less stress.

The issue is with the /config/environments/production.rb and /config/application.rb configuration files. I will post my copies of these files further below. For now I want to explain the important configurations settings.

The first thing to check is that the asset pipeline is enabled. Make sure config.assets.enabled is set to true in your application.rb file:

config.assets.enabled = true

In that same file you also want to ensure that the following is set to false:

config.assets.initialize_on_precompile = false

This setting is required in order to get your rails app properly deployed to Heroku or Cloud66+Digital Ocean. I use the word properly because setting this to true will enable assets to be compiled live as the app is running. This uses much more memory and leads to poor performance. Make sure you set this to false to have assets precompiled before running (this is explained later in this post).

You will most likely want to compress your Javascript files and have the default Ruby gem uglifier handle the compression for you (you can read more about this in the Ruby on Rails documentation). In your production.rb file make sure the following setting is set to true:

config.assets.compress = true

You will then want to ensure that all of your CSS and Javascript files will be included. In your production.rb file make sure config.assets.precompile is set to the following:

config.assets.precompile = [ /\A[^\/\\]+\.(ccs|js)$/i ]

The above two settings were the causes of my issues. After fixing the settings above I noticed Javascript errors in my console when I tried to precompile my assets. This eventually led me to discovering a missing “}” in one of my CSS files. Make sure that these two asset precompile settings are set properly so that you can solve any potential syntax issues locally in development mode.

Now that those configurations have been set you are ready to precompile your assets in your local development environment. To precompile your assets, type the following in your console:

bundle exec rake assets:precompile

Once this operation completes you may see errors like I did. Carefully read through the errors to pick out the error message, the file that caused the error, and the line number where it may be occurring.

After your assets are precompiled you will need to commit your changes and push them to your git respository:

git add .

git commit -a -m “precompiled assets”

git push

Lastly you will need to push the newly precompiled assets to your Production deployment. For Heroku, simply push your code to your server with the following:

git push Heroku master

For Cloud66, click on the Deploy icon on your dashboard to deploy with your new code changes.

Here are my production.rb and application.rb files for your reference:

production.rb

AppName:Application.configure do
# Settings specified here will take precedence over those in config/application.rb

if defined?(Bundler)
# If you precompile assets before deploying to production, use this line
Bundler.require(*Rails.groups(:assets => %w(development test)))
# If you want your assets lazily compiled in production, use this line
#Bundler.require(:default, :assets, Rails.env)
end

module AppName
class Application < Rails::Application
# Settings in config/environments/* take precedence over those specified here.
# Application configuration should go into files in config/initializers
# — all .rb files in that directory are automatically loaded.

# Custom directories with classes and modules you want to be autoloadable.
# config.autoload_paths += %W(#{config.root}/extras)

# Only load the plugins named here, in the order given (default is alphabetical).
# :all can be used as a placeholder for all plugins not explicitly named.
# config.plugins = [ :exception_notification, :ssl_requirement, :all ]

# Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
# Run “rake -D time” for a list of tasks for finding time zone names. Default is UTC.
# config.time_zone = ‘Central Time (US & Canada)’

# Use SQL instead of Active Record’s schema dumper when creating the database.
# This is necessary if your schema can’t be completely dumped by the schema dumper,
# like if you have constraints or database-specific column types
# config.active_record.schema_format = :sql

# Enforce whitelist mode for mass assignment.
# This will create an empty whitelist of attributes available for mass-assignment for all models
# in your app. As such, your models will need to explicitly whitelist or blacklist accessible
# parameters by using an attr_accessible or attr_protected declaration.
config.active_record.whitelist_attributes = true

# Enable the asset pipeline
config.assets.enabled = true

# Version of your assets, change this if you want to expire all your assets
config.assets.version = ‘1.0’

I purchased my SXSW Interactive badge in July last year but I will be unable to attend. I am willing to sell my SXSW Interactive 2013 badge for the price I paid plus the transfer fee. I paid $695 for the badge and the transfer fee is $125. I’ll sell the badge for a total of $820.

Feel free to ask me any questions regarding the badge in the comments below or on Twitter.