【簡単】webフォントを使用する方法 ーgoogle web font編ー
css3からwebフォント機能を使用することができるようになりました。 これによって、わざわざ使用したいフォントファイルをサーバーにアップロードすることなく、気軽に使用したいフォントを使用することができるようになりました。
しかしながら、webサーバーにアップロードするわけではないので、フォントの読み込みが発生します。 そのため、webサーバーにアップロードする場合と比べて、読み込み時間が長くなってしまいます。その上、日本語（カタカナ・漢字・ひらがな）に対応するフォントの場合さらに、読み込みに時間がかかってしまうのでご注意ください。
それでは、実際にどのようにwebフォントを使用していきます。
google web fontsで使用したいフォントを探す
Google Fonts こちらにアクセスしましょう。
おすすめのgoogle fontsについては、こちらを参照しましょう。 おすすめのGoogle Web Fonts 25選 | それからデザイン スタッフブログ
今回は、Sorts Mill Goudyを使用します。
使用するフォントが選択したら、検索欄にフォント名を入力して、真ん中の→矢印ボタンを押しましょう。
そうすると、フォントの太さを選択する画面に移動することができます。今回はitalicも使用したいので、italicも選択します。
あとは下にスクロールしてこのリンクをコピーして、サイトの
タグに貼り付けるだけです。
え？Cloud9を使用しているのにEmmet使ってないの？
プログラミング初心者におすすめしているCloud9 * 無料 * 環境構築が楽 * クラウド
などなど多彩な魅了を持っているのですが、実は、Emmetも標準装備なんです。
Emmetとは
Emmetとは、一言で表すと、「HTMLとCSSを爆速でコーディングできるようになるプラグイン」です。
例えば、ヘッダーでaタグを複数書かなければならない時がありますよね。
<header>
<li><a href="">トップ</a></li>
<li><a href="">お問い合わせ</a></li>
<li><a href="">トピックを投稿する</a></li>
<li><a href="">マイページ</a></li>
<li><a href="">ログアウト</a></li>
</header>
こういった時に、いちいち<li>や<a>を何回も書くのは面倒ではありませんか？
Emmetを使用すれば、こんなめんどくささから開放され、爆速で
コーディングできるようになります。
実際にEmmetを使ってみる
例えば、Emmetを使用すれば、先ほどのヘッダーリンクを作成するコードは、こうなります。
header>li*5>a[href=""]
たったこれだけです。
これをタブキーを押すだけで、
こんな感じに展開されます。
詳しくEmmetを使用したい方はこちらの入門記事を読むのがおすすめです。
ちなみに、emmetを起動させるキーは、Cloud9の場合 tabキーになっているのでご注意ください。
deviseで認証メールのリンクを押すと、ログイン状態になるようにする方法
deviseのデフォルトの設定では、認証メールを押して、またログインしなければなりません。これは、メールアドレスを間違って新規登録してしまった場合、他人にログインされてしまうという危険性があるためです。 しかし今回は、そのセキュリティ問題を無視して、認証メールを押すとそのままログインするという機能を実装します。
Devise::ConfirmationsController#showをオーバライドする
やり方は、簡単です。 app/controllers/users/confirmations_controller.rbを作成します。
class ConfirmationsController < Devise::ConfirmationsController def show super do |resource| sign_in(resource) end end end
superとすることで、deviseのconfirmations controllerのshowメソッドを呼び出すことができます。
ここで注目して欲しいのは、sign_in(resource)です。
この文を書き加えることで、最終的に、ログインさせる状態に無理やりしています。
routes.rbを編集する
最後にroutes.rbを編集します。先ほど、confirmations controller作成したためです。
devise_for :users, controllers: { confirmations: "confirmations" }
,controllers: {
confirmations: "confirmations"
}
を追記します。
これで、認証メールのリンクを押すとログイン状態にすることができます。 簡単に実装できますが、セキュリティに難があるのが問題ですね。
イラストレータ超基本 アートボードを複製する方法
イラストレータ超初心者です。
アートボードを複製する方法を学びましたので、共有します。
今まで、アートボードを複製する時は、アートボードツールで頑張って幅を合わせながらやっていましたが、最近買ったリファレンス本を見て感動しました。こんなやり方があるとは....
例えば、こんな感じのアートボートを複製したいとします。
そんな時は、右下のアートボート画面から複製したいアートボードを選択し
右下のアートボード複製ボタンにドラッグアンドドロップするだけです！（一番下の紙みたいなボタン）
Rails + Ajax でエラーメッセージを実装する。
最近、同僚の人が、ajaxでエラーメッセージを実装していたので、勉強になりました。
ちなみに、ajaxで実装していたコメント機能に、エラーメッセージをつけるというものになります。
form viewにエラーメッセージを実装する
まず、エラーメッセージをform viewの中に実装しましょう。 このエラーメッセージは、scaffoldを実装する時にも、自動実装されるよくあるやつです。
【作業】
<% if @comment.errors.any? %> <div id="error_explanation"> <h2><%= pluralize(@comment.errors.count, "error") %> prohibited this comment from being saved:</h2> <ul> <% @comment.errors.full_messages.each do |message| %> <li><%= message %></li> <% end %> </ul> </div> <% end %>
【作業終わり】
<div id="error_explanation">
ajax処理のための、idを加えています。
controllerにエラーが出た時のajax処理を加える
コントローラーにエラーが出た時の、処理を加えます。
def create @comment = current_user.comments.build(comment_params) respond_to do |format| if @comment.save render :index, status: :created, notice: 'Comment was successfully created.' else render :error, status: :unprocessable_entity end end end
また、事前にviewにremote: :trueを加えてあるので、jsレスポンスがはしります。
viewのjs.erbを作成する
コントローラの次のviewを作成します。
views/comments/index.js.erb
$("#comments_area").html("<%= j(render 'comments/index' %>"); $('#error_explanation').remove(); $(':text').val('');
views/comments/form.js.erb
$("#comment-form").html("<%= j(render 'comments/form') %>");
form.js.erbはエラーメッセージの時だけ、発火し、index.js.erbは発火するとエラーメッセージを消します。
これで、ajaxでエラーメッセージを実装することができます。
また、本文では、escape_javascriptをjと略しています。 qiita.com
deviseとparanoiaを使用して論理削除を実装する
前回の続きです。 blog.eifukun.tokyo
deviseにはデフォルトでemailにユニーク制約がついていたり、validatableモジュールがあるので、論理実装を行うことができません。 そこで、今回はdeviseとparanoiaを使って論理実装するための方法について調べてみました。
論理実装をすることによって、退会したユーザが、退会した時と同じメールアドレスで登録できるようにします。
deviseのvalidatableを編集する
【作業】
まずは、user.rbにてvalidatableモジュールの読み込みを解除します。
app/models/user.rb
devise :database_authenticatable, :registerable,:confirmable, :recoverable, :rememberable,:trackable # :validatable
emailのユニーク制約以外はそのままにしておきたいので、オーバライドしてユニーク制約だけを削除します。
app/models/user.rb
def self.included(base) base.extend ClassMethods assert_validations_api!(base) base.class_eval do validates_presence_of :email, if: :email_required? # validates_uniqueness_of :email, allow_blank: true, if: :email_changed? validates_format_of :email, with: email_regexp, allow_blank: true, if: :email_changed? validates_presence_of :password, if: :password_required? validates_confirmation_of :password, if: :password_required? validates_length_of :password, within: password_length, allow_blank: true end
【作業終わり】
validates_uniqueness_of :email, allow_blank: true, if: :email_changed? をコメントアウトします。これによって、emailのユニーク制約を削除します。
ちなみに、本家のvalidatableモジュールはこちらにあります。 github.com
これで、emailのユニーク制約を、削除することができました。
migration fileを作成する
class DeviseCreateUsers < ActiveRecord::Migration # 中略 add_index :users, :email, unique: true end
デフォルトのmigrationファイルは、このようにユニーク制約が、カラムにも追加されています。こちらも削除しましょう。
【作業】
rails g migration
などでマイグレーションファイルを作成しましょう。
次に、マイグレーションファイルの中身を、以下に書き換えましょう。
class ChangeUniqueIndexEmailAndDeletedAtToUsers < ActiveRecord::Migration def up remove_index :users, :email add_index :users, [:email, :deleted_at], unique: true, name: 'index_users_on_email_and_deleted_at' end def down remove_index :users, [:email, :deleted_at] add_index :users, :email, unique: true end end
【作業終わり】
def up def down ってなんぞ？ という方は、こちらをお読みください。 tanihiro.hatenablog.com
[:email, :deleted_at]と指定することで、email + deleted_atでユニーク判定できるようになります。
また、複数カラムを設定すると、インデックス名が長くなるので、nameオプションでインデックス名を指定しています。
paranoia_uniqueness_validatorでモデル側にも、設定を加える
マイグレーションファイルを編集することで、データベースに email + deleted_atのユニーク制約を設定することができました。
しかし、モデル側には、まだ加えることができていないので、追加します。 サーバー高負荷時などにユーザが２度登録ボタンを押してしまい、モデルでユニーク制約を記載していたのに同じ値がDBに登録されてしまうという問題が発生するためです。
Rails 4でモデルのバリデーションまとめ - Rails Webook
モデル側の設定には、 anthonator/paranoia_uniqueness_validator - ... - GitHub を使用します。
【作業】
models/user.rb
validates :email, uniqueness_without_deleted: true
【作業終わり】
uniqueness_without_deletedでdeleteda_atもユニーク制約に加えることができます。DBと同様です。
これでdeviseとparanoia( paranoia_uniqueness_validator)を使用して論理削除を実装することができました。
修正点・改善点・疑問点などありましたら、コメントを頂けると嬉しさMAXです。
Spacial Thanks
論理削除とは何か、調べてみた
最近、「論理削除って普通の削除と、どう違うんですか？」 と聞かれた時にすごい困ったので、論理削除について調べてみました。
論理削除と普通の削除（物理削除の違い）
普通にデータ（登録ユーザなどの情報）をデータベースからDELETE（Railsだと destroyとか）で削除することを、物理削除といいます。 物理削除をするとデータは消えてなくなってしまいます。見ることができなくなります。
一方、論理削除とは、データベースにフラグとなるフィールドを作成しておき、削除時に削除フラグを立てることにより、仮想的に表示時に見えなくしてしまう処理になります。つまり実際には、データは削除されません。
※フラグについて
フラグとは、コンピュータにおいて、処理結果を真（True）/偽（False）いずれかの値で保持するレジスタまたは変数のこと。条件が合っていれば真(True)、否であれば偽(False)である。真の場合を「フラグが立っている」、偽の場合を「フラグが落ちている」と言い、また真にすることを「フラグを立てる」、偽にすることを「フラグを倒す」（あるいはフラグを降ろす、落とすとも）と言う。
論理削除を実装するメリットについて
論理削除で実装することによって、データを消さずに、あたかもデータが消えたように振る舞うことが可能になります。 例えば、解約したユーザが、「やっぱり解約を取り消したい」ということは、多々あります。これを、実装するためには、物理削除ではなく、論理削除で実装する必要があります。
論理削除を実装するデメリットについて
勿論、論理削除を実装することによって、生じるデメリットもあります。
・SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる ・全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい ・例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる ・データ不整合と場当たり的クエリの巣窟になる ・削除フラグの立ったデータが大量に隠れている ・一律でdeleteフラグがあると、削除しても大丈夫なテーブルであるかのようなイメージを与える。 cf: 論理削除が奪うもの
上記事項について、把握する必要はありませんが、論理削除を実装することによって、気をつかわないといけないことがかなり増えます。
論理実装する時には、本当に論理実装が必要なのか一度再考してみましょう。
