他の人がブログとqiitaをどう使い分けているか、13個の記事を調べてみた。

調べた結果、qiitaに受けた印象

qiitaは、自分の技術的な記事で繋がるSNSという感じがしました。読者がプログラマーで、反応が得られやすいです。個人ブログで専門的なことやニッチなことを書いても、なかなか人が集まらないでしょう。集まったとしても反応がもらえるかはわかりません。その点qiitaを使えば、SEOもしっかりしており、人の目につきやすいです。

ただ、あーだ、こーだと自分の意見や考えを書かないという使い方が多かったです。qiitaにはSNSの機能はゆるく付いているだけで、一番の目的は、下記の公式の引用通り、プログラミングに関する知識を記録・共有するためなのだと思いました。他のブロガーの方たちは、事実を書くことを重要視されていました。

Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。
Qiitaとは - Qiita

ブログとqiitaのメリットとデメリット

ブログと比較した時のqiitaのメリットは、アクセス数と反応の良さという意見が多かったです。ブログだと、そのブログを自分で育てた充実感があるのなら、qiitaには誰かの役に立ったという充実感が生まれやすいのでしょう。または、承認欲求が満たされるという言うのかな。

ブログのメリット

  • ブログを自分で育てたという充実感がある。
  • 自由にブログの見た目などをカスタマイズできる。
  • 内容を気にせず、書くことができる。
  • プログラム以外の内容も書ける。
  • 実験的な内容を書くことができる。
  • ひっそりと書くことができる。
  • アフィリエイトが堂々とできる。
  • アクセスがqiitaよりも集まりにくい。
  • プログラムという専門性の高い記事だと、反応が貰える可能性が低い

ブログのデメリット

  • アクセスが集まりにくい。
  • SEO対策を自分でしないといけない。
  • 環境構築などの準備を、自分でやる必要がある。
  • 維持費がかかる場合もある。

qiitaのメリット

  • アクセスがブログよりも多くなりやすい。
  • SEO対策を自分でする必要がない。
  • ブログのように環境構築が必要ない。
  • 記事の拡散性が高い。
  • 記事に対するFB(フィードバック)が得られやすい。
  • ストックで承認を得ることができる。
  • ブログよりも、誰かに見られるという緊張感を持って書くことができる。
  • 読者がプログラマーである。
  • 技術的な記事が集まる。
  • 無料で使える。

qiitaのデメリット

  • 書く内容が技術的な内容に限られる。
  • 反応がもらいやすい分、批判されやすい可能性も。
  • 実験的なことは書けない。
  • 書く内容に対するハードルが、ブログよりも高い。
  • アフィリエイトが堂々とできない。
  • 紹介や告知などができない。
  • サイトの見た目などをカスタマイズできない。

どんな内容を書くのか

qiitaに書く内容は、プログラミングに関することがメインみたいです。後は、プログラマーが関心を持つことですかね。作ったツールの紹介を書かないと言う意見もありましたが、便利なツールなら解説を沿えばありなのでは思いました。便利なツールなら、拡散されやすいが私はいいと思います。既にqiitaに投稿されている、作ってみた系の記事でも500ストックオーバーのものもありました。これだけストックされているのなら、作ってみた系の記事も受け入れられているのでしょう。

作ってみた系のストック500オーバーの例
Qiita - 無料でイントラネット内にナレッジ/ノウハウの共有ができる「Lodge」 - Qiita

紹介記事に対しての意見

「○○を作りました」「○○をリリースしました」系の話題は、Qiitaよりも個人のブログのほうが良い気がします。紹介は知識というよりアナウンスに近いような気がするからです。
Qiitaとブログの使い分け | #interest_ae

ブログに書く内容

  • 日記
  • 自分の考えや意見
  • 自分の勉強記録
  • イベントの告知
  • 作ったものの紹介
  • 技術的以外のこと
  • 技術的だが、実験的な内容

qiitaに書く内容

  • プログラミングに関すること
  • プログラマーが関心を持つこと
  • 事実
  • 客観的な情報
  • 検証結果
  • 作ったツールの紹介

qiitaに投稿するのは、ハードルが高いのでは?

qiitaだとブログよりも自由に書けない分、ハードルが低いという意見もありました。ですが、検証結果ということで、実行結果のログを載せてみるのはどうでしょうか?これなら初心者でも、確実な事実を書くことができます。

投稿後に、成長すれば間違いにも気づけます。その都度、修正・加筆を繰り替えていけばいいですね。

紙の本を書いているわけではないので、「公開=内容の確定」にする必要はない、というのが僕の考え方です。
長めのブログやQiita記事を書くときの、僕なりのノウハウ - give IT a try

コードリーディングの記事はどちらに書こう?

私はコードリーディングをした際に、コメントを残したソースコードをgistにあげています。
impress.jsのスライドを管理する配列

まだかなり断片的な内容なのでgistに上げていますが、どこかでgitリポジトリに変更しようと思っています。このようなコードの解説も、qiitaに上げるといいかなと思いました。私自身がOSSのコードリーディングをしたことがなかったので、こういうものがあると非常に助かりました。

qiitaには連載記事など、記事が複数にまたがる場合は、自分で目次の記事を書き、そこに書く記事のリンクを手動で貼り付けているようでした。1記事1テーマというのが方針で、これはしょうがないのかな。もし、qiitaに書いたとしてもコメントを付けたソースコードは、gitリポジトリでも管理しようと思います。そのリポジトリの紹介を、体系的な解説を含めてqiitaに書くのがいいのかもしれませんね。

プログラマーの知り合いを探すなら、qiitaを活用しよう!

qiitaはストックや、コメントでのFB(フィードバック)もあり、反応が得られやすいです。もし、周りにプログラミングをやっている知り合いがいなく、探している場合はqiitaがいいかもしれません。話題はプログラムに限定されていて、読者もプログラマー。それでアクセスも多く、フォローなどのSNSの機能もあります。技術系の記事を自分のブログで書くより、とても繋がりやすいかと。

ただし、人が集まりやすく、繋がりやすい分、色々な人がいると思った方がいいです。トラブルになりやすい人も見かけたことがあります。私も人のことを言えませんが、qiitaだから他のSNSより安全そうと思い、油断するのは危ないということです。

参考にした記事

  1. 個人ブログとQiitaの使い分け方について考えてみたよ | CreativeStyle
  2. Qiitaとブログの使い分け | #interest_ae
  3. Hatena BlogとQiitaの使い分け方 - NEGOLOG
  4. Qiitaとブログの使い分け方を考えてみた - 趣味プログラマによるOSS開発日誌
  5. #kobitoapp と #qiita とblogの関係について考えた - pblog
  6. For X Developers: 【備忘録の在り方を考える】一週間毎日Qiitaに投稿してわかったこと
  7. 初めてアウトプットしてみたよ! - supermannerの落書き
  8. qiitaとブログの使い分け | Catalion Log
  9. 最近、Qiitaで書いてます: uessay
  10. 頭の整理 - Qiita と Blog と - Qiita
  11. 長めのブログやQiita記事を書くときの、僕なりのノウハウ - give IT a try
  12. 僕がブログを書く前、書くとき、書いたあと - give IT a try
  13. ブログに技術メモする前にQiitaにも投稿しようよ! - 25歳ニートが35万円で上京を企むブログ

CoffeeScriptでプライベート変数を定義する方法

CoffeeScriptのプライベート変数は、コロンではなくイコールで

下記は、人間に自己紹介させるクラスです。_nameはプライベート変数にしてあります。CoffeeScriptでは、プライベート変数はクラス定義の直下に書きます。プラベートメソッドの場合は、変数の値の代わりに関数を指定すればいいです。とにかくプライベートの場合は、コロンではなくイコールを使って定義しましょう。class内で、コロンを使うと、メソッドになってしまいます。プライベートメソッドの場合は、イコールを使うところに注意です。

CoffeeScriptでは、変数宣言ができない

CoffeeScriptには、varがないので変数の宣言のみを記述することができません。なので、今回は初期値として_nameには空文字を入れています。空文字も嫌な人は、undefinedを初期値として代入してあげればいいです。

JavaScriptでは、クロージャでプライベート変数を作る

下記は、上記のcoffeeファイルを、コンパイルして整形したjsファイルです。Humuanという変数には、無名関数の中によって定義されたHuman関数が戻り値として代入されています。JavaScriptでクラスを擬似的に表現するのに、関数を使います。

このHuman関数はコンストラクタになります。この関数の中で参照している_name変数は、Human関数の外側で定義したものです。このように自分の関数定義より、外側のコンテキストから変数を参照すると、内側の関数を実行しても、変更した内容が保持されます。これがクロージャです。

thisでインスタンスとバインドしないから、プライベート変数になる

もし、Human関数のコンストラクタ_nameではなく、this._nameとしてしていたら、このthisはHuman関数によって作成されたインスタンスを指します。このようにthisのプロパティとして変数を紐付けることをバインドと言います。

Human関数で生成されたインスタンスを通してアクセスできるのは、このようにthisでバインドされたものです。_namethisインスタンスにくっつけてたりせず、全然関係ないところで定義されたものを使っています。だから、Humanクラスのインスタンスを通してアクセスすることが出来ないのです。結果として、プライベート変数になります。

railsの複合ユニーク制約をshoulda_matchersでテストする

Railsのユニーク制約をshoulda-matchersを使ってテストしてみました。結果として、このマッチャーは複数カラムをまたいだ制約の時は使わない方がいい気がしました。1つのカラムでのユニーク制約も、複数カラムのユニーク制約も同じ扱いになっているようです。

ちなみに、undefined methodと表示される場合はshoulda-matchersのバージョンを2.8に落とすと直ります。3.0の不具合みたいです。

rspecでundefined method validate_presence_ofとエラーが出る

rspecundefined method validate_presence_ofというエラーがでました。not null制約のためにvalidate_presence_ofを使ったのですが、こんなメソッドないと言っています。他のプロジェクトでは使えていたので、比較してみるとバージョンに問題がありました。

エラーが出てた方のshoulda-matchersというgemが3.0.0だったのですが、使えてた方は2.8.0でした。なのでバージョンを2.8.0に落としたところ無事テストが完了しました。

gemsetからvendor/bundleにgemを移したら、rspecコマンドがつかえなくなった

vendor/bundlebundle insatllすればrbenbのgemsetを使う必要がなくなったので、gemsetを削除して切り替えました。するとbin/rspecが使えなくなりました。bin/rspecrspecの実行ファイルなので、これを自動作成する時の読み込みパスがgemsetのどこかになっていたのかと思い、次のコマンドで再インストール。

bundle binstubs rspec-core --force

無事使えるようになりました。

コマンド「QUEUE=resque_sample rake environment resque:work」を読み解く

Railsのコントローラで定義したメソッドの中で、長い処理は非同期で行いたいときはありませんか?例えばユーザー登録のメール送信などは、コントローラのメソッドの中でメールが送信されるまで処理を止めるのではなく、非同期にして先に「登録が完了しました。」とページを表示させてあげる。こういうのをrailsでやるのにresqueというgemが役立ちます。

このgemのチュートリアルである下記の記事を試してみました。

Hello World Resque (Railsにresqueを導入する) | hello-world.jp.net

今回は定義したキューを実行させるための下記のコマンドを掘り下げて見ていこうと思います。

QUEUE=resque_sample rake environment resque:work

ちなみに次のように書いても実行できます。QUEUEを後ろに回しただけです。

rake environment resque:work QUEUE=resque_sample

QUEUEは環境変数で、どの種類のタスクを実行するのか決めている

QUEUE=resque_sampleQUEUEという環境変数を定義して、そこにresque_sampleという文字列を格納しています。その後にrakeでタスクを走らして、そのタスク内でこの環境変数の中身を使っているわけです。

参考:Linux - シェル変数と環境変数の違いをコマンドラインで確認する - Qiita

簡単な例をあげます。 ruby_script_testとうファイルを作り、次のとおりに記述します。その後chmod 755 ruby_script_testコマンドラインから実行して、このファイルに実行権限を与えてあげましょう。

#!/usr/bin/env ruby
puts ENV['SAY']

そしてコンソールで次のように打ってください。環境変数の中身が出力されましたね。

% SAY=hello
% ./ruby_script_test
hello

rubyで記述されたファイルをrubyコマンドなしで実行できる仕組みは下記が参考になります。簡潔にまとめると、ファイルの拡張子があろうがなかろうか、1行のめシバンとよばれる#!~の記述でどのコマンドで実行すればいいかをファイル自体に記述しているからrubyコマンドなしで実行できるわけです。

ruby - rubyで作ったプログラムをターミナルからコマンドで実行したい。 - スタック・オーバーフロー

ちなみに、QUEUEresque_sampleを指定していますが、これはapp/workers/hello.rb@queue = :resque_sampleと記述したからです。@queue = :another_taskとした場合は、QUEUE=another_task rake environment resque:workと実行しなければなりません。

キューというのはタスクをやることリストとして管理するためのもので、それをいくつか名前をつけて用意できます。今回だと、resque_sampleanother_taskという2種類のキューを試したわけです。QUEUE= resque_sample rake environment resque:workとはresque_sampleというキューに登録されたタスクを消費し始めるとコマンドです。「消費し始める」が重要ですよ。このコマンドを実行していなくても、今回のチュートリアルの/helo/worldというページにアクセスすればResque.enqueueが実行されてキューにどんどん溜まっていきます。その後にQUEUE= resque_sample rake environment resque:workを実行すれば、溜まったタスクがどんどん実行されていくので、ページにアクセスしなくても実行されているように見えます。

実際にはRedisというKVSのDBに、「resque:queue:ワーカ名」の配列としてどんどんジョブが格納されていきます。そして実行が終わるたびに配列から要素が取り出されていきます。詳しくは下記を参考。

Resqueで色々やって、Redisに何が格納されているのか調べてみた - kitak.blog

environmentはモデルを読み込むために使う

rakeコマンドにenvironmentという引数を渡しています。これを渡すことによってタスク内でActive Recordのモデルなどを使用できるようになります。下記はrake user:registで実行できるタスクです。中でUserモデルを使用しています。これはtask関数でenvrionmentを渡しているからです。これを削除したらUserモデルは使えなくなってしまいます。

# lib/task/user.rake
namespace :user do
  desc "ユーザーを登録するタスクです。"
  task regist: :environment do
    User.create(name: '太郎')
  end
end

しかし、この記述がなくてもUserモデルをタスク内で使える方法があります。それが最初にあげたコマンドのrake environmentです。コマンドラインからenvironmentを渡しているのでモデルなどが使用できるようになるわけです。

参考:[rails]Rakeタスクでのtask定義の「:environment」引数について | アプレンティス プラクティス

resque:workというタスクはどこで作られる?

lib/tasks/resque.rakeというファイルを作成して、require 'resque/tasks'という記述を書きましたよね。resque/tasksを読み込むことによって自動で作られるみたいです。githubのlib/resuq/tasks.rbを見てみましょう。コメントにもこれをrequireしたらresqueタスクが作られると書いてありますよね。それとnamespace :resqueの中にtask :workが定義されていることも確認できます。

# require 'resque/tasks'
# will give you the resque tasks
require 'resque/cli'

namespace :resque do
  task :setup

  desc "Start a Resque worker"
  task :work => [ :preload, :setup ] do
    warn "DEPRECATION WARNING: Rake tasks are deprecated. Use `resque work` instead"

    opts = [
      "-q", ENV['QUEUES'] || ENV['QUEUE'] || "*",
      "-t", ENV['RESQUE_TERM_TIMEOUT'] || 4.0,
      "-d", !ENV['BACKGROUND'].nil?,
      "-p", ENV['PIDFILE'],
      "-i", ENV['INTERVAL'] || 5
    ]

    Resque::CLI.new([], opts).invoke(:work)
  end
# 略
end

【やる夫で学ぶRedisの雰囲気】String型とHash型でクラスの名簿管理

KVSのRedisがRDBとどう違うのか?実際に使っているところを見ながら確認したいと思い、「やる夫で学ぶ」シリーズとして作成してみました。基本ログに一言添えただけです。詳しい説明は載せていません。次の目的に使えるかと思います。

  • Redisの雰囲気を掴みたい
  • KVSでどんな風にデータを管理するのか知りたい
  • 実際に使っているシミュレーションで学びたい
  • Redisのサンプルを見たい

実際に下記のサンプルを色々変えて打ってみて、エラーを出したりして各コマンドの意味を掴んでいくと身につくと思います。