WireFrame: Balsamiq vs Moqups

Balsamiq

The tool ship with varies different version, there’s a subscription version online and a desktop version. The desktop version support both PC and Mac.

On first impression, balsamic allow you to quick design either a web page or mobile application. It ships with elements or controls that allow you to quickly drag and drop then with minimal fuse.

I really like Balsamiq for the near zero learning curve and the only cons is that you need to working on either a PC or MAC to use this.

VS

Moqups,

This is a subscription-based version, the learning curve and features are very similar to Balsamic.

As it is build on the latest HTML 5 technology, I can work on the wireframe on any iOS device via the Safari app. Obviously, trying to design it on a iPhone will be a challenge.

 

moqups.com

Custom Layout for Devise

Custom Layout in Devise, devise is an awesome gem that provides the quick and easy way for the rails app to have user authentication.

But you may be face with the need to add a custom layout to devise. There’s a couple of ways of doing so, but today I am going with the easiest way without bloating your codes.

In Application.rb in config, add the following section.


config.to_prepare do
Devise::RegistrationsController.layout "conversation"
end

This will apply the conversation layout to the Devise::RegistrationsController.

You will need to have the conversation.html.erb layout in the appviewslayouts folder.

Visit the following article to understand more on the layouts

http://www.carrotcoded.com/2015/05/03/layout-in-ruby-on-rails/

Layout in Ruby on Rails

Introduction

Layout in ruby on rails provide the flexibility to allow different views to come together and render as a page. Think iFrame but we without the cross-domain issue.

Layout are located in your project, appviewslayouts, by default you will only have application.html.erb

Layout will always have the  <%= yield %> tag, this will render the current controller/action.

What is this important?

Imagine this, you have a Landing Page for public users to visit the application and now you have a Dashboard Page where the users sign in.

These two pages will have different layout for sure. You will also want to ability to maintain them separately and maybe reuse some of the codes that you have developed as part of the project.

How do I then do it?

Taking the example above, say you have a Landing Page and a Dashboard page.

You will also have the controllers for them HomeController and DashboardController respectively.

Within the respective controller, after the class declaration, the first line end the following code

layout “public”

public will be the name of your layout file in the appviewslayouts folder.

application.html.erb is the default that will be applied to the rest without any additional setting.

Sample of the Layout for HomeController.

class HomeController < ApplicationController
layout "public"

Tutorial – Building a Support Ticket System on Rails – Part 2

We are going to create the following in this tutorial:

  • Ticket Model
  • Ticket Controller
  • Ticket Views

Here we going to take the easy way out by having rails generate all the above for us, using a single command.

1. Open Terminal and key the following:

-> rails g scaffold Ticket ticketnumber:integer ticketTitle:string ticketDescription:string status:string date:datetime uid:string resolution:string

Now in the project directory, a lot of new stuff files are generated for you as well as configuration of routes are done up.

2. Now to create the table in the database

-> rake db:migrate

3. Now we need to set the default page that is going to be loaded by the application.

Browse to config/routes.rb, add the following line into the file.

-> root ‘tickets#index’

4. Next we want the application to validate that the user is signed before access any pages.

Browser to app/controllers/tickets_controller.rb, add the following line after the class TicketsController <ApplicationController.

-> before_action :authenticate_user!

5. Testing time!

-> rails s

Browse to http://localhost:3000/

 

Tutorial – Building a Support Ticket System on Rails – Part 1

From the start of this year, I will try to start writing more tutorial post instead of snippet of technology post.

For a start, I will be talking about the recent Support Ticket System that I build on Rails.

Duration: 30 mins

Let’s create a new Rails application.

1. Open up Terminal, enter the following command to generate the project

-> rails new SupportTicketSystem

This should generate all the relevant files and the necessary files structure.

2. Configuration of Devise

2.1 Access the project folder and locate the Gemfile, add the following line.

gem ‘devise’

We are going to use Devise here to help you manage your users. For more information on Devise visit the following,https://github.com/plataformatec/devise

2.2 Next up from the Terminal, access the folder and run the following command.

-> bundle install

In some case, due to how your machine is setup, you may need to run it will ‘rake’ infront

-> rake bundle install

2.3 Run the following command to setup Devise.

-> rails g devise:install

OR

-> rails generate devise:install

Both of the above does the same thing but the first option is a short hand method of rails.

2.4 Now we are going to specify the Users data so that Devise is aware of it and create the database table.

-> rails g devise User

->  rake db:migrate

To verify the above setup, go to app/models/user.rb

You should see the User.rb being created and that the context of the file should be similar to what I have.

class User < ActiveRecord::Base
# Include default devise modules. Others available are:
# :confirmable, :lockable, :timeoutable and :omniauthable
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :trackable, :validatable
end

2.5 We going to add a new column to the User Model, call Type.

This type will allow the system to know if the user is a customer or a support engineer.

Now go to the terminal again.

-> rails g migration add_type_to_user type:string

-> rake db:migrate

Now you have added a new column to the database table!

2.6 Setting different user type via Enum. Open up User.rb in app/model

Add the following code:

enum type: [:SupportEngineer, :Customer, :Admin]

2.7 Lets generate some UI from Devise

-> rails g devise:views users

2.8 Controller!

-> rails g controller Users

Now go into the file, users_controller.rb in the following location, app/controller

We need to change the “ApplicationController” to Devise::SessionController

class UsersController < Devise::SessionsController
end

Now go to routes.rb in your app/config and make sure that devise_for:users is there.

2.9 Now to test 

In terminal, do the following command to start the server.

-> rails s

Open up your browser, http://localhost:3000/users/sign_up

WildCard Search in Ruby on Rails

Wildcard Search

Assuming that you have you have the following model:

Model : Book

Fields: 

  • BookName
  • Author
  • PublishedDate
  • Edition

Typical, when you try to do a wildcard search you will do the following code below:

Book.where(“BookName LIKE ‘%#{BookNameInput}%’)

The above returns the following in terms of SQL ->

SELECT “Books”.* FROM “Books” WHERE (BookName LIKE ‘%BookNameInput%’)

Problem:

This makes you vulnerable to SQL Injection, for more information visit, http://railscasts.com/episodes/25-sql-injection?view=asciicast

Solution:

Use the following syntax instead:

Book.where(“BookName LIKE (?)” , “%#{BookNameInput}%”)


Additional information:

If you want to do WILDCARD SEARCH and ignoring case sensitivity, use iLIKE instead of LIKE.

 

 

Redirect After OmniAuth Sign in With Devise

class AuthenticationsController < ApplicationController def create auth = request.env[“omniauth.auth”] user = User.find_by_provider_and_uid(auth[“provider”], auth[“uid”]) || User.create_with_omniauth(auth) sign_in_and_redirect(:user, user)

end end

 

Add the line in bold to redirect!

OmniAuth & Devise: Validation failed email and password cannot be blank

If you are using Devise as the authentication for your Ruby On Rails application and you are looking to implement OmniAuth, that allow the users to login with their Facebook or Google Account.

But once you have all the codes and omniauth setup, on creation you will hit the following error:

Validation Failed: Email and Password cannot be blank. Background

The issue here is that the Devise model that you are working with will have the following :validatable added as part of the model. This is to validate that the database authentication have both the email and password before creation of the account.

But with omniauth, we may not get the email or do the user need the password to login, they simply use the relevant account for the different providers, such as Twitter, Facebook or Google to login.

Solution

We will need to overwrite the default Devise validation. Using the following methods below. Just copy them to your model and you should be good.

 

def email_required? super && provider.blank? end def password_required? super && provider.blank? end

 

Note : provider is a field or column in your model.

Validation failed: Password can’t be blank