この記事は Crystal Advent Calendar 2015 の 15 日目の記事です
昨日は Kemal の開発者である sdogruyol さんの記事でした。
今日は、私 pine613 が次の Crystal 勉強会の告知記事を書きます!
- 2016年1月22日 (金) に Cookpad さんで開催決定
この記事は Crystal Advent Calendar 2015 の 15 日目の記事です
昨日は Kemal の開発者である sdogruyol さんの記事でした。
今日は、私 pine613 が次の Crystal 勉強会の告知記事を書きます!
Goals:
Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n
concurrent flows.
After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?
It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed
class Dog | |
attr_writer :name | |
def initialize(name) | |
@name = name | |
end | |
def bark | |
puts "patrick" | |
end |
Node.js is just JavaScript running on the server side. That's it. That's all there is to it.
As your business logic gets complex you may need to implement transactions. The classic example is a bank funds transfer from account A to account B. If the withdrawal from account A fails then the deposit to account B should either never take place or be rolled back.
All the complexity is handled by ActiveRecord::Transactions
. Any model class or instance has a method named .transaction
. When called and passed a block, that block will be executed inside a database transaction. If there's an exception raised, the transaction will automatically be rolled back.
This guide assumes that you recently run brew upgrade postgresql
and discovered to your dismay that you accidentally bumped from one major version to another: say 9.3.x to 9.4.x. Yes, that is a major version bump in PG land.
First let's check something.
brew info postgresql
The top of what gets printed as a result is the most important:
set :application, "My Static Content" | |
set :servername, 'test.example.com' | |
# no git? simply deploy a directory | |
set :scm, :none | |
set :repository, "." # the directory to deploy | |
# using git? deploy from local git repository | |
# set :scm, :git | |
# set :repository, 'file//.' # path to local git repository |