Why I moved from capistrano to mina to deploy my app?

To be honest, I have just started to use deployment tools because doing the same thing over and over again was getting very tedious for me. I first started with capistrano and it was good I guess.

Why I prefer Mina over Capistrano?

While Capistrano is a really really great tool , it is terribly slow. Since time is money for every one of us, I wanted a tool that would not be so painfully slow and easy to use, you know , that get shits done. Then I met Mina and instantly fell in love with it when I browsed its homepage and read its slogan "Really fast deployer  and server automation tool" .

Before I was using any deployment tools I was manually ssh`ing into my server and then cloning the repo from the git then running bundle install , rake db:migrate and a lot of stuffs that is not very interesting to do repeatedly. If I had pushed any new updates to the repo I would have to ssh into the server and do the same thing which is time consuming as well as not very productive. So I highly reckon anyone who is not using deployment tools to use it and feel its power. But remember Great power comes with Great responsibility. :)

It is dead simple to get started with Mina. All you have to do is add a gem run the bundler, create a deploy.rb file , fill the right info in it and running mina deploy. The best part is you can write rake tasks in deploy.rb.

Either run gem install mina or add mina gem in your gemfile.
Run bundle install if you chose the later option.
run mina init in your working directory
Here is my deploy.rb file
require 'mina/bundler'
require 'mina/rails'
require 'mina/git'

# Basic settings:
#   domain       - The hostname to SSH to.
#   deploy_to    - Path to deploy into.
#   repository   - Git repo to clone from. (needed by mina/git)
#   branch       - Branch name to deploy. (needed by mina/git)

set :user, 'ubuntu'
set :domain, 'www.fuitter.com'
set :deploy_to, '/usr/share/nginx/html/fuitter'
set :repository, 'git@bitbucket.org:mc_cannibal/fuitter2.git'
set :branch, 'master'
set :forward_agent, true

# Manually create these paths in shared/ (eg: shared/config/database.yml) in your server.
# They will be linked in the 'deploy:link_shared_paths' step.
set :shared_paths, ['config/database.yml', 'config/secrets.yml', 'log']

# Optional settings:
#   set :user, 'foobar'    # Username in the server to SSH to.
#   set :port, '30000'     # SSH port number.
#   set :forward_agent, true     # SSH forward_agent.

# This task is the environment that is loaded for most commands, such as
# `mina deploy` or `mina rake`.
task :environment do
  ruby_version = File.read('.ruby-version').strip
  raise "Couldn't determine Ruby version: Do you have a file .ruby-version in your project root?" if ruby_version.empty?
 queue %{
   source /home/ubuntu/.rvm/bin/rvm
   rvm use #{ruby_version} || exit 1
 }
end

task :setup => :environment do
  queue! %[mkdir -p "#{deploy_to}/#{shared_path}/log"]
  queue! %[chmod g+rx,u+rwx "#{deploy_to}/#{shared_path}/log"]

  queue! %[mkdir -p "#{deploy_to}/#{shared_path}/config"]

  # Add the repository server to .ssh/known_hosts
  if repository
    repo_host = repository.split(%r{@|://}).last.split(%r{:|\/}).first
    repo_port = /:([0-9]+)/.match(repository) && /:([0-9]+)/.match(repository)[1] || '22'

    queue! %[
      if ! ssh-keygen -H  -F #{repo_host} &>/dev/null; then
        ssh-keyscan -t rsa -p #{repo_port} -H #{repo_host} >> ~/.ssh/known_hosts
      fi
    ]
  end

  # Create database.yml for Postgres if it doesn't exist
  path_database_yml = "#{deploy_to}/#{shared_path}/config/database.yml"
  database_yml = %[production:
  database: fuitter
  adapter: postgresql
  pool: 5
  timeout: 5000]
  queue! %[ test -e #{path_database_yml} || echo "#{database_yml}" > #{path_database_yml} ]

  # Create secrets.yml if it doesn't exist
  path_secrets_yml = "#{deploy_to}/#{shared_path}/config/secrets.yml"
  secret =
  secrets_yml = %[production:
  secret_key_base:
    #{`rake secret`.strip}]
  queue! %[ test -e #{path_secrets_yml} || echo "#{secrets_yml}" > #{path_secrets_yml} ]

  queue! %[chmod g+rx,u+rwx,o-rwx "#{deploy_to}/#{shared_path}/config"]

end

desc "Deploys the current version to the server."
task :deploy => :environment do
  to :before_hook do
    # Put things to run locally before ssh
  end
  deploy do
    # Put things that will set up an empty directory into a fully set-up
    # instance of your project.
    invoke :'git:clone'
    invoke :'deploy:link_shared_paths'
    invoke :'bundle:install'
    invoke :'rails:db_migrate'
    invoke :'rails:assets_precompile'
    invoke :'deploy:cleanup'

    to :launch do
      # queue "mkdir -p #{deploy_to}/#{current_path}/tmp/"
      # queue "service #{user} restart"
    end
  end
end

# For help in making your deploy script, see the Mina documentation:
#
#  - http://nadarei.co/mina
#  - http://nadarei.co/mina/tasks
#  - http://nadarei.co/mina/settings
#  - http://nadarei.co/mina/helpers

then run mina setup and finally mina deploy.
That is all there is to it.

Why I would avoid materializecss for my next app?

Material design is taking over the UI/UX by storm these days so I also decided to give materializecss, a CSS framework, a try. I heard about this framework through my colleague and it did surprised me with its tons of cool effects.

So for my app, Fuitter, I added the framework using the materializecss gem because I was not able to make the fonts work by manually adding the links to files.(it was a bummer)

Materializecss have everything I needed for my app`s design, like the side nav bar, wave in the buttons and more. While the materializecss team is doing a great job with its framework, I am planning to not use it anymore in the future.

I wanted a select field for the TLD in the domain section and I rendered it  using rails form helper but after I refreshed my page the select field was not rendered, it was present in the DOM but it was hidden. I had to spend a good one hour before the Eureka moment hit me. The default select field in materializecss overrides the browser default property, so to render it I had to use javascript and that is not cool. So why the heck this is not cool? What if I had dynamically created select fields? Meteorjs renders view on the fly , so I would have to write tons of logic in each template to initialize the select every time the view loads.

<%= form_tag() do %>
    www.
    <%=  text_field_tag(:domain_name) %>
    <%= select_tag(:tld, options_for_select([['.com', '.com'], ['.org', '.org']])) %>
<% end %>

This will be hidden until you add some javascripts.
<script>

$(document).ready(function() {
    $('select').material_select();
});

</script>

So, the design of select functionality in materialize CSS is, in my opinion, a pretty good reason not to use it.


By the way, the wave effects in the buttons also has the same problem.

While materializecss provides a lot about all the 'effects' modern apps will demand I'm not sure those types of designs and concepts fit into large scale software just yet.