To run this blog, I must admit that I encountered some problem to have everything working.
Because of that, I wrote for myself a simple guide to setup a deployment enviroment with Ubuntu/Debian, and I would to share it (tested on Ubuntu 12.04).
Put you code under version control
This is the first step to deploy your code. I use git
, to install it (you can find it here).
After installation, init your app
cd yourapp
git init
git add .
git commit -m "initial commit"
Deployment
SSH Stuff
To connect to your deployment machine I recommend to setup a custom SSH connection.
Generate a key on the development machine:
Walk through the key generator and set a password, the key file by default goes into ~/.ssh/id_rsa
.
Next, you need to copy the generated key to the remote server where you want to setup password-less login with
cat ~/.ssh/id_rsa.pub | ssh user@remotehost 'cat >> ~/.ssh/authorized_keys'
And then edit the file ~/.ssh/config
to have something like that:
Host host
HostName remotehost
User user
IdentityFile ~/.ssh/id_rsa
After you have restarted your shell, check if login works password-less
The next steps have to be executed on your deployment machine.
Install Ruby and Rails
To deploy, you have to install Ruby and then Rails. To do it, I would recommend you to use RVM (Ruby Version Manager) instead of APT, because lets you to install multiple Ruby versions and use them all together.
So, no more chatting! Install ruby + rails via RVM and then load it in all opened shells
curl -L https://get.rvm.io | bash -s stable --rails
source ~/.rvm/scripts/rvm
Install Nginx + Passenger
To make Rails works with your favorite web server, you have to install the Passenger’s gem and module.
I used nginx, but for Apache is pretty similar.
Install the gem and then install nginx with Passenger’s module
gem install passenger
rvmsudo passenger-install-nginx-module
This step could take some minutes, but if everything goes ok, copy these lines to /opt/nginx/conf/nginx.conf
passenger_root /home/user/.rvm/gems/ruby-1.9.3-p194/gems/passenger-3.0.17;
passenger_ruby /home/user/.rvm/wrappers/ruby-1.9.3-p194/ruby;
Setting the preferences of your webserver inside http { … }
server {
listen 80;
server_name yourapp.com;
root /home/youruser/public_html/yourapp/current/public;
passenger_enabled on;
access_log /home/user/public_html/yourapp/current/log/access.log;
error_log /home/user/public_html/yourapp/current/log/error.log;
}
Be sure to point to current/public
folder!
Then, create a script to control nginx:
wget -O init-deb.sh http://library.linode.com/assets/660-init-deb.sh
sudo mv init-deb.sh /etc/init.d/nginx
sudo chmod +x /etc/init.d/nginx
sudo /usr/sbin/update-rc.d -f nginx defaults
You can now control nginx with this script
sudo /etc/init.d/nginx stop
sudo /etc/init.d/nginx start
Install your favorite DB
I installed MySQL, not my favorite but one of the most known.
sudo apt-get install mysql-server mysql-client
sudo apt-get install libmysql-ruby libmysqlclient-dev
gem install mysql2
(I used mysql2
gem because is better than its old daddy mysql
. More info here)
Install node.js
One of the other things you’ll want is Node.js. This will help you do the compiling of assets on deployments
sudo apt-add-repository ppa:chris-lea/node.js
sudo apt-get -y update
sudo apt-get -y install nodejs`
Deploy with capistrano
To deploy, the first step is to create a remote repository in which push your code, so SSH into your deployment machine and create it.
# on remote-deployment machine
mkdir -p ~/git/yourapp.git
cd ~/git/yourapp.git
git --bare init
Then, add gem 'capistrano'
to your Gemfile, install it
and set git
to push to you deployment machine
bundle pack
git add Gemfile Gemfile.lock vendor/cache
git commit -m "bundle gems"
git remote add origin host:git/yourapp.git
git push origin master
The last thing to do is to edit the file config/deploy.rb
to let Capistrano to work with your deployment machine.
Set :deploy_to
to your public folder in which you have your webserver’s files.
set :user, 'user'
set :domain, 'yourremotehost'
set :application, 'yourapp'
set :repository, "host:git/#{application}.git"
set :deploy_to, "/home/#{user}/public_html/#{application}"
ssh_options[:keys] = %w(~/.ssh/id_rsa)
# miscellaneous options
set :deploy_via, :remote_cache
set :scm, 'git'
set :branch, 'master'
set :scm_verbose, true
set :use_sudo, false
Finally, init capistrano
check if everything works
run your migrations
and deploy your app
git add .
git commit -m "add cap files"
git push
cap deploy
Do not hesitate to tell me “Hey, you wrote a lot of bullshit!”, because it’s possibile that I forget something.
Do not expect that everything works the first time because there is a lot of stuff, but this worked for me so I hope it works for you too.
Only ten days ago, I was writing about how beautiful is Ruby and how powerful is Ruby on Rails to develop web applications.
Today, I have (almost) finished to develop this blog.
I don’t know if you noticed some changes because I tried to no upset the CSS, but under the hood everything is different.
Now this blog runs as a Ruby on Rails application in my dedicated Amazon EC2 instance. I left Wordpress to have the total control of the source code and to add only features which I care about.
I decided (for now) to continue using MySQL, but I’m tempted to switch to PostgreSQL or MongoDB in the near future to try something different.
This is my first project in Rails (obviously!), but I’m pretty pleased of my work.
Features
Until now I implemented these features:
- Posts with **markdown** syntax and draft option
- Categories (but not tags, I hate them)
- Users
- Authentication with salted password
- Unit tests
- Admin panel to manage posts and users
- HTML and CSS
- Code syntax highlighting
- Twitter Bootstrap integration
- Comments with Disqus
But there are also some tasks that I want to realize:
- Functional and integration tests
- Image uploading (at this moment Cloud App or FTP is my friend)
- Responsive layout (if there is a CSS magician here, let me know :D)
If you are interested you can find the source code on GitHub.
Please feel free to send me every feedback or issue tracking, both here or on GitHub.
Why another CMS?
To people who ask me why I have done another CMS, I would cite Marco Arment about his project Second Crack (which is, exactly, another CMS):
Don’t a lot of these static-file blogging engines already exist?
Yes.
Isn’t this reinventing the wheel?
Yes.
Don’t you have other things you could be working on?
Yes. (Don’t we all?)
What have you done differently from [existing solution]?
A bunch of small things, probably. I don’t know enough about the other solutions to really say.
Why doesn’t it have [feature]?
Because I didn’t think [feature] needed to be there. Some anticipated frequent values for [feature]:
- Comments: Use Disqus or Facebook comments. Or just go without comments. Do you really need them?
- Stats: Use Google Analytics or Mint. (Or both.)
- Widgets and dynamic page content: Use Javascript.
- Dynamic rendering for automatic mobile layouts, etc.: Use CSS.
Why should I use this instead of [existing solution]?
I don’t know. You probably shouldn’t.
Will this make you, me, or anyone any money?
I doubt it.
So why did you make this?
Because I’m a programmer, and this is what I do.
Some people jog away from their house every day, only to jog back. Others walk on a treadmill, expending energy to get nowhere. In both cases, it may appear to others that they’ve accomplished nothing, but they’ve chosen to do these seemingly redundant activities on a regular basis to incrementally improve themselves. And it works.
A couple of weeks ago I decided to learn Ruby to take advantage from the most acclaimed framework of last years: Ruby on Rails.
My background of web application developer was PHP-only, so I didn’t know any framework such as Cake or Zend.
In the last months every time I started a new project I felt afraid because my code used to get dirty after some hundreds of lines, probably because mere PHP and MVC-pattern were no best friends.
When I was going to start to learn Cake, I have been stopped: “Learn Rails!”, said a voice in my head. And after only a week I can say that I have to buy it [the voice, E.d] a beer, but maybe it’s not enought.
From a developer with a “relatively deep” Java and C-related background, I love Ruby because it’s strongly typed and meanwhile there’s no static type checking.
I love its light syntax and every character that I don’t type on my keyboard against to other more verbose languages like Java or Obj-C.
I have not yet played deeply with modules and mixin to realize multiple inheritance, but I will.
But talking about Rails, I’ve to admit: Ruby on Rails is the state of art of all existing frameworks.
The speed and smartness to have stuff working is amazing. I think there are only few others languages/frameworks to realize the real AGILE software developing as you can do with Rails.
Every line of code you’ll write, it’s predisposed to be tested (with unit, functional and integration tests) with automatic templates and without need of plugins or other stuff.
The DRY (Don’t Repeat Yourself) logic is taked to the extreme (maybe too much, the amount of total files is huge!) and every piece of the puzzle fits perfectly.
Coding and coding, I’m amazed every day more of how this framework works and how fast I can build a web application. The road to be fluent in Ruby is long, but I’m excited to learn all can I do.
And as Sam Ruby said:
Consider spending less time talking and more prototyping
I’m using MongoDB for my thesis work, and unquestionably it is full of great features. I choose it for its awesome handling of geo-located documents and its quick queries.
There are many other excellent features:
- you can index ANY attribute
- “agile and scalable” as 10gen says
- very quick
- awesome documentation and drivers for any language
- integrated Map/Reduce (even if too slow)
- Apache licence
- and so on…
But on the other side there are many features not exactly friendly.
In this great article, a zopyx’s employee explains why they said “goodbye mongodb”.
He criticized these features:
Locking: a global lock for any operation is like a suicide
Query language: not very easy (for who already knows SQL)
Map/Reduce: its slowness is due to the monothread Javascript engine (for that reason, I used MongoDB+Hadoop in my thesis)
Journaling: MongoDB pre-allocates 3 GB of data for journaling - independent of the actual database size(s) - insane for small installations
I completely agree with him. In particular on locking and Map/Reduce problems.
The employee ends his article with
MongoDB is currently more about marketing and hype than it deserves. The primary goal of 10gen is currently running through the world in order to tell the world how cool MongoDB is.
Here I disagree. MongoDB has a great potential and 10gen’s guys are working hard and well to improve their project.
That’s the question I made myself: why should I start a new blog? The answer is easily explained: I’m a developer but first of all I consider myself a student, so I’ll want to write about everything I am interested in (and I hope you too), such as web technologies, design patterns, mobile platforms, best coding practices, user interface design, computer networks, security, artificial intelligence… and so on, exploring a lot of fields of programming and computer science.
I code mainly for iOS, so you have to excuse me if most of articles are about it.
So, let’s start!