LaravelでRSSリーダーを作っている

feedlyはスタイリッシュすぎるので、泥臭いRSSリーダーを作っている。

Niche Reader
http://reader.nicheantenna.com/

未読管理機能は、消化に追われるたちなので意図的につけてない。
カテゴリのフィルタ機能は、必要になったら作る予定。。。

高速化というか、操作でストレスがたまらないようにするために、JavaScriptでインライン表示とかはせず、問答無用でページ遷移するようにした。
（速いJavaScriptを書ける気がしてない）。

一応、スマホで見れるようにレスポンシブ化してある。

今まで使ったことのなかったLaravel(バージョン4)で作った。
この前バージョン5が出たので、早めに移行したい。

最近はマイクロフレームワーク主義だったが、Laravelはすごく便利なので、フルスタック主義にかえりつつある。
まだ使い始めてそんなにたっていないので、「Laravel最強！」って声高にいうつもりはない。

CSSはLessで書いて、gulpで自動ビルド。規則はBEMに則ってる。
正直、BEMは見た目がアレすぎるので、「__」を「-」にしている。
「--」は「_」にしようかと思ったが、そのままにしている。
単語の区切りは「-」で書くとなっていたが、キャメルケースにすることで、記号（-）を減らした。

定期的にRSSは取り込むバッチは、Rubyで書いた。
以前、アンテナサイトを作ったときのものを、ほぼそのまま流用した。

サーバーはさくらのVPSの1Gのやつ。
さくらのVPSは体感速度が速くて、とても好きです。
（けっして、石狩記念タオルをもらったから宣伝してるわけではないんだぞ！）。
こういうのはHerokuかAWSで動かすのがトレンドなんだろうけど、VPSもいいよね。

あと作りたい機能は、「カテゴリ（or タグ付け）機能」「一括インポート機能」くらい。
意外と、すんなり作れたのは、きっとLaravelさんのおかげ。

『Team Geak』を読んだ

年末なにか本を読もうと思って、Team Geakを読んだ。

リーダー（マネージャー）になるエンジニア向けの内容が多い。

以下、メモ。

ソフトウェア開発はチームスポーツである 

コードを隠さない

コードや作業を隠してもいいことはない（≒ アイデア/意見を隠さない）。

適切なフィードバックをもらったほうが、結果としていい仕事ができる。

作業を隠したいという欲求は、批判に対する不安からうまれる。

途中の作業を隠すよりも、フィードバックをもらった方がいいし、フィードバックをもらうことに慣れよう。

ひとりで作業して、しょうもないことで止まったりすると、時間がもったいない。

作業を隠したほうが、失敗に対するリスクは大きくなる。

また作業を隠すとプロジェクトのバス係数も大きくなる。

プロジェクトの詳細を知っているのが自分だけなら、自分がバスに轢かれてしまったら、その時点でプロジェクトも死んでしまう。

もし他にひとりでも詳細を知っていれば、プロジェクトは（たぶん）生き残る。

このときバス係数は２倍。

チームで働くための三本柱

謙虚（Humility）・・・自分が正しいとは限らない。常に自分を改善していく。

尊敬（Respect）・・・一緒に働く人を思いやる。

信頼（Trust）・・・自分以外の人は有能で、正しいことをすると考える。そうすれば、仕事を任せることができる。

合わせて HRT と呼ぶ。ハートと読む。

コード批判について

「自分は、自分の書いたコードではない」

この言葉を自分だけきちんと認識していたところで意味は無い。

チーム共通の認識になっていなければ意味がない。

「このコードは間違っています。○○パターンを使うべきです」

→「この部分がわからないのですが、○○パターンなら読みやすくなるでしょうか」

相手への疑問でなく、自分の疑問として謙虚に聞く。

注意深く、相手を不快にさせないように。

過去の失敗をドキュメント化する

Googleでは「ポストモーテム（検死解剖）を書く」という。

謝罪ではなく「何を学んだか」「何を変更したか」を書く。

そして、みんなが読める場所に置く。ドキュメント化する。

早い段階で失敗・学習・反復しよう。

コミュニケーションの原則

同期コミュニケーションを減らし、非同期コミュニケーションを増やす。

この本ではメーリングリストを推している。自分はグループチャットがいいのではと思った。

ミッションステートメント

目指すこと・目指さないことを明確に決める。

エンジニアがひと目で理解できるように。

「価値のある会社を目指します」「株主への価値を生み出す」→全然具体的でなく意味わからないからダメ。

チーム内での認識の違いを明らかにして、プロダクトの方向性を導く。

技術的な方向性も含む。

コミュニケーション手段

・メーリングリスト（→ちょっと時代遅れと思っていたが、まだまだ現役らしい）

・オンラインチャット・・・プライベートチャットでなくグループチャットを使おう！

・バグ管理ツール・・・優先順位をつける。掲示板と同じ。衆目に晒す。

・コードコメント・・・何を書かない。なぜを書く。　→リーダブルコードあたりを読むといいかも？

・コードレビュー・・・第３者の目。

船にはキャプテンが必要

「マネージャー」ではなく「リーダー」と呼ぼう。

※ Googleではマネージャーは「部下がいる」という意味でしかないらしい。

・Googleでのリーダーの種類

TL（チームリード）・・・プロダクトの技術的方向に責任を持つ

TLM(テクニカルリードマネージャー)・・・TLに加え、チームにいるエンジニアのキャリアや幸せに責任を持つ。

マネージャーの評価軸

エンジニアの評価軸をコードのような制作物でみなすと、マネージャーの評価軸がゼロになってしまう。

ピーターの法則

「階層的な組織に属する人間は、必ずその人の無能レベルまで昇進する」

結果を出せなくなる役職まで昇進し続ける（結果が出る役職ならば昇進できる）。

採用

「Aランクの人はAランクの人を採用する。Bランクの人はCランクの人を採用する」

触媒になる

多くの場合、適切な答えを知るよりも、適切な人を知る方が価値がある。

注意散漫→自発的

エンジニアが注意散漫なら、方向性が必要。

何をすべきかを理解して、構造化スキルを身につけて、管理可能なタスクに分割する。

退屈→興奮

エンジニアが退屈しているならば、モチベーションが必要。

モチベーションは外発的動機と内発的動機の２種類ある。

外発的動機・・・金

内発的動機・・・

　・自律性・・・プロダクトにオーナーシップを感じる

　・熟達・・・新しいスキルを学んだり、すきるを向上させる。

　・目的・・・顧客からの役に立ったメールなど

組織を操作する

悪い習慣をやめることはできない。良い習慣と置き換えなければいけない。

悪い悪いというだけでなく、代案を出して悪い習慣を良い習慣に置き換えていこう。

感想

ついついコードなどを隠しがちだが、積極的に作業を表に出すようにする。

これはオープンソースがどうという話でなく、チームとして仕事に取り組む上で、

コードを隠すとフィードバックをもらえなくなてしまって損だよ、ということ。

仕事では進捗報告が遅れがちになることもあるので、肝に命じようと思った。

リーダー（マネージャー）レベルの話が多く、自分はいまその立場にないのだが、

エンジニアのモチベーションの話などは自己分析に役立つと感じた。

エンジニアはエンジニアらしく、積極的に会社に良い習慣を植え付けていこう。

PHPのバージョン管理はphpbrewが使いやすいです

PHPのバージョンを管理するソフトウェアはphpbrewが一番使いやすいです。
なので、みなさんもphpbrewを使いましょう。

c9s/phpbrew · GitHub

インストール方法や使い方はREADMEを見るのが一番いいです。

インストールメモ

以下、自分向けのメモ。

phpbrewのインストール。

$ curl -O https://raw.github.com/c9s/phpbrew/master/phpbrew
$ chmod +x phpbrew
$ sudo cp phpbrew /usr/bin/phpbrew

初期設定コマンド。

$ phpbrew init

.bashrcか.zshrcに以下のコマンドを追記する（端末起動時にphpbrewの設定ファイルを読み込むようにする）。

source ~/.phpbrew/bashrc

Homebrewを使ってる場合は、以下のコマンドを叩くといいらしい。
（以前はする必要なかった気がするが、最新バージョンでは必要っぽい）
（これに関してはぶっちゃけ何してるかよく知らない）

$ phpbrew lookup-prefix homebrew

PHPのインストールはこんな感じでできる。

$ phpbrew install 5.4.0 +default

「+default」の部分はvariantsといって、PHPのconfigureオプション（インストール時に指定する拡張モジュールなど）を指定するもの。

variantsは以下のコマンドで詳細を確認できる。

$ phpbrew variants
Variants: 
  all, apxs2, bcmath, bz2, calendar, cgi, cli, ctype, dba, debug, dom, embed, 
  exif, fileinfo, filter, fpm, ftp, gcov, gd, gettext, hash, iconv, icu, 
  imap, intl, ipc, ipv6, json, kerberos, mbregex, mbstring, mcrypt, mhash, 
  mysql, openssl, pcntl, pcre, pdo, pgsql, phar, posix, readline, session, 
  soap, sockets, sqlite, tidy, tokenizer, xml, xml_all, xmlrpc, zip, zlib


Virtual variants: 
  dbs: sqlite, mysql, pgsql, pdo
  mb: mbstring, mbregex
  default: bcmath, bz2, calendar, cli, ctype, dom, fileinfo, filter, ipc, 
  json, mbregex, mbstring, mhash, mhash, pcntl, pcre, pdo, phar, posix, 
  readline, sockets, tokenizer, xml_all, zip, bz2

「+default」を指定すると、

 default: bcmath, bz2, calendar, cli, ctype, dom, fileinfo, filter, ipc, 
  json, mbregex, mbstring, mhash, mhash, pcntl, pcre, pdo, phar, posix, 
  readline, sockets, tokenizer, xml_all, zip, bz2

がインストールされることがわかる。
こだわりがないなら+defaultは付けた方がいい。

インストールできるPHPのバージョンは、

$ phpbrew known

で確認できる。

今のところPHP 5.5が最新系。
こだわりがないなら一番新しいのでいいと思う。

自分は以下のようなオプションでインストールしてる。

$ phpbrew install 5.5.8 +default +mysql +apxs2 +openssl

（追記:20140115:OpenSSLのオプション追加した）

+aspxはapacheを使用するときに指定する（以下、若干うろ覚え）。

Macだと/usr/libexec/apache2に書き込み権限がないと警告かエラーが出たと思う。
いろいろ面倒なので自分は/usr/libexec/apache2のパーミッションを777に。
（phpbrewを使うような環境はローカルの開発環境だと思うし）

$ sudo chmod 777 usr/libexec/apache2

またapache2の設定ファイル（Macだと「/etc/apache2/httpd.conf」）にも書き込み権限がないと警告orエラーが出た気がする。
これはphpbrewが生成したPHPのモジュールの読み込み設定を追加しようとするため。
書き込み権限追加するか、それが嫌なら自分で設定を書く（自分はさくっと書いちゃってます）。
既存の設定をコメントアウトし、同じようなフォーマットでphpbrewでインストールしたモジュールを読み込むようにする。

#LoadModule php5_module libexec/apache2/libphp5.so
LoadModule php5_module libexec/apache2/libphp5.5.8.so

なんかバッドノウハウ感あるので、良い方法があったら誰か教えて下さい。

PHPのバージョン変更

使用するPHPを指定する場合は、以下のコマンドを実行します。

$ phpbrew use 5.5.8     # 一時的に5.5.8に変更する(端末を再起動したら元のバージョンに戻る)
$ phpbrew switch 5.5.8  # デフォルトで使用するバージョンを5.5.8に変更する(端末を再起動しても5.5.8のまま)

まとめ

phpbrew便利。

Module#prepend

Module#include

クラスAがモジュールMをincludeすると、メソッドの探索順は A → M → …のようになる。

つまり、モジュールMはクラスAの親クラス側に差し込まれる。

module M
  def hello
    puts "M hello"
  end
end

class A
  include M

  def hello
    super
    puts "A hello"
  end
end

A.new.hello
# => M hello
# => A hello

p A.ancestors  # 自身と親クラスの配列を返す
# => [A, M, Object, Kernel, BasicObject]

Module#prepend

Module#prependはクラスの子側(?)にモジュールを差し込む。

したがって、モジュールのメソッドで、インスタンスのメソッドをラッピングできる。

module M
  def hello
    puts "before"
    super
    puts "after"
  end
end

class A
  prepend M

  def hello
    puts "hello"
  end
end

A.new.hello
# => before
# => hello
# => after

p A.ancestors  # 自身と親クラスの配列を返す
# => [M, A, Object, Kernel, BasicObject]

差し込まれる順番は自然。

Module#includeはクラスのすぐ後ろ(親側)に追加していく。

Module#prependは先頭(子側)に追加していく。

module M1; end
module M2; end

class A
  include M1  # A -> M1
  include M2  # A -> M2 -> M1 (Aのすぐ後ろに追加していく)
end

class B
  prepend M1  # M1 -> B
  prepend M2  # M2 -> M1 -> B (先頭に追加していく)
end

p A.ancestors  # 自身と親クラスの配列を返す
# => [A, M2, M1, Object, Kernel, BasicObject]

p B.ancestors  # 自身と親クラスの配列を返す
# => [M2, M1, B, Object, Kernel, BasicObject]

Module#includeはメソッドの前に何かを実行するってことができなかったけど、Module#prependではそれができる。

メソッドの前後に処理を(自然に?)追加できるので便利ですね！

参考リンク

Ruby 2.0 : Module#prepend

Module#prepend - alias_method_chainが滅ぶ日 - I am Cruby!

Slimで改行のあるHTMLを出力する

SlimはHamlによく似たテンプレートエンジンです。
%記号がないので、より書きやすくて見やすいです。

Slimで出力すると改行のないHTMLが出力されます。
今まで汚いなーと悩んでましたが、ドキュメントに整形（改行とインデント）して出力する方法が普通に書いてあった。

Slim::Engine.default_options[:pretty] = true

どうやら速度が遅いからデフォルトで改行やインデントをしないみたいです。
変なHTMLを出力するのは嫌だし、今のところ速度を気にするような状態ではないので改行を入れるようにしてます。
速度が問題になったらそのとき対策を考えます。

package.el便利じゃないですかー！

VimのVundleやNeoBundleがすごく便利で、emacsでモダンなパッケージマネージャを使いたかったのだが、どれもパッとしなかった（当社比）（あと僕はemacsモヒカンではないので趣味趣向が合わなかった可能性があるという予防線を張っておきます）。

んでどうしたものかなーと思っていたら、emacs24にデフォルトでのるpackage.elなるパッケージマネージャがあるらしく、emacs23でも(たぶん22でも）使えるみたいなので、試してみた。便利すぎて吹いた。

パッケージ一覧の表示が遅かったりするけども、まぁそんな何回も起動するわけじゃないしね、と割り切る。

設定方法はEmacs Lisp を簡単にインストールするための package.el & MELPA #elisp #Emacs - Qiitaを見るとよい。
ただ僕の手元にauto-installがなかったので(!)、

• 「.emacs.d」にpackage.elを置いて、
• 「.emacs」に「.emacs.d」へのロードパスとpackage.elの設定を書いた。

emacsをたちあげて、

M-x package-list-packages

とすると、パッケージファイルの一覧を表示できる。そこからインストールもできる。

今いる行のパッケージに対して、

i	インストール指定
u	インストール指定取り消し
x	インストール実行

を操作できる。検索とかはC-sでできる。

最近やたらとよく見かける「自由なソフトウェア」について

最近とある御方のブログを読んで、「自由なソフトウェア」なるものに興味を持ったのでメモ。

自由なソフトウェアとは

自由なソフトウェアの定義などは以下のページが詳しい（というか本家）。
自由ソフトウェアとは? - GNUプロジェクト - フリーソフトウェアファウンデーション (FSF)

少し引用。

「自由ソフトウェア」は、利用者の自由とコミュニティを尊重するソフトウェアを意味します。おおよそで言うと、利用者は、ソフトウェアを実行、コピー、配布、研究、変更、そして改良する自由を有します。

http://www.gnu.org/philosophy/free-sw.ja.html

自由なソフトウェアという呼び方

「自由なソフトウェア」という呼び名は少々まどろっこしいと思うかもしれない。
だが「フリーソフトウェア(free software)」という表現を使ってはいけない。
フリーソフトウェア＝無料で使えるソフトウェアという誤解が広まっており、明確に自由なソフトウェアを指さなくなったからである。
free softwareのfreeには無料という意味が含まれるため、この誤解が生まれたようだ。

日本語では「自由なソフトウェア」と呼ぼう。
フリーソフトは“自由なソフト”と呼ぼう--リチャード・ストールマン氏 - ニュース - nikkei BPnet

関係ないけどハッカーがクラッカーと同じ意味で使われてるために「正義のハッカー」と書くのと状況が似てますね。

自由なソフトウェア≠オープンソース

オープンソースが意味するのは、ソースコードを見ることができるということである。
だが、ソースコードが公開されているからといって、それが自由なソフトウェアとは限らない。

例えば、擬似フリーなソフトウェアは自由なソフトウェアとは呼べない。

疑似フリーソフトウェアとは、フリーではないが、非営利目的であれば 個人の利用や複製、頒布、改変(改変されたバージョンの頒布を含む)を 許可しているソフトウェアのことです。

http://www.gnu.org/philosophy/categories.html#semi-freeSoftware

非営利のような条件の付くソフトウェアは自由とは言えないのである。

自由なソフトウェアで利益を得ること

自由なソフトウェアによって利益を得ることは禁じられていない。
むしろ、推奨されている。

多くの人々は、GNUプロジェクトの精神とはソフトウェアの複製物を配布するにあたりお金を課してはならないということだ、とか、もし取るにしても配布コストをまかなうに足るだけの、できるだけ小額の手数料しか取ってはいけないということだ、と信じています。これは誤解です。

実際のところわたしたちは、自由ソフトウェアを再配布する人々に、お金を望むだけ、あるいはできるだけ課すことを推奨しています。これを知ってびっくりした方は、続けて、お読み下さい。

http://www.gnu.org/philosophy/selling.ja.html

自由なソフトウェアで利益を得る方法は、いくつか提案されている。
僕自身とても興味があることなので、別記事にまとめようと思っている。

「ソフトウェアを売る」という表現は、誤解を招く可能性があるので注意が必要だ。

人々が「ソフトウェアを売る」ということを考えるとき、大抵は多くの会社がやっていることと同じようなことを思い浮かべます。
すなわち、ソフトウェアを自由ではなく、プロプライエタリにするということです。

http://www.gnu.org/philosophy/free-sw.ja.html

ソフトウェアのコピーを、手数料を取って頒布するのは適切である。
だが、ソフトウェアを売るという表現をすると、プロプライエタリ（独占的な）ものを想像してしまう。

自由なソフトウェアという観点から見たJava

以下の記事を読んでね（はーと
本の虫: Javaの権利にまつわるまとめがすごい