- 作者: 押切蓮介
- メディア: Kindle版
- この商品を含むブログを見る
OpenShiftのVagrantfileはParallelsには対応してないようだ
環境: OSX Yosemite, Parallels, Vagrant(v1.6.5)
Vagrantのparallelsプラグインはインストール済み。
OpenShiftを引っ張ってくる。
$ mkdir -p $GOPATH/src/github.com/openshift $ cd $GOPATH/src/github.com/openshift $ git clone git://github.com/openshift/origin $ cd origin
Parallelsだとエラーが出る。
$ vagrant up --provider=parallels Bringing machine 'openshiftdev' up with 'parallels' provider... There are errors in the configuration of this machine. Please fix the following errors and try again: vm: * A box must be specified.
Virtualboxだと大丈夫。
$ vagrant up --provider=virtualbox Bringing machine 'openshiftdev' up with 'virtualbox' provider... ==> openshiftdev: Box 'fedora_inst' could not be found. Attempting to find and install... (略)
Vagrantfileを見ると、それっぽい記述がある。
vagrant_openshift_config = { "instance_name" => "origin-dev", "os" => "fedora", "dev_cluster" => false, "insert_key" => true, "num_minions" => ENV['OPENSHIFT_NUM_MINIONS'] || 2, "rebuild_yum_cache" => false, "cpus" => 2, "memory" => 1024, "virtualbox" => { "box_name" => "fedora_inst", "box_url" => "https://mirror.openshift.com/pub/vagrant/boxes/openshift3/fedora_virtualbox_inst.box" }, "vmware" => { "box_name" => "fedora_inst", "box_url" => "http://opscode-vm-bento.s3.amazonaws.com/vagrant/vmware/opscode_fedora-20_chef-provisionerless.box" }, "libvirt" => { "box_name" => "fedora_inst", "box_url" => "https://mirror.openshift.com/pub/vagrant/boxes/openshift3/fedora_libvirt_inst.box" }, "aws" => { "_see_also_" => AWS_CRED_FILE, "box_name" => "aws-dummy-box", "box_url" => AWS_BOX_URL, "ami" => "<AMI>", "ami_region" => "<AMI_REGION>", "ssh_user" => "<SSH_USER>", }, "openstack" => { '_see_also_' => OPENSTACK_CRED_FILE, 'box_name' => "openstack-dummy-box", 'box_url' => OPENSTACK_BOX_URL, 'flavor' => "m1.tiny", 'image' => "Fedora", 'ssh_user' => "root", },
所感
OpenShiftをいじってみているが、よくわからん。
v3 からDocker, Kubernetes ベースに変更されたらしい。
参考リンク
Usage - Vagrant Parallels Provider Documentation
origin/CONTRIBUTING.adoc at master · openshift/origin · GitHub
Niche Readerをユーザー登録しなくても使えるようにした
Niche Reader - http://reader.nicheantenna.com/
個人のWebサービスにメールアドレスを要求するのはよくない気がしてきたので、 URLにランダムなトークンを割り当てて、そのURL(トークン)を知っている人だけがアクセス出来る形にしてみた。
Gistのプライベート、GoogleMapのリンク共有と同じ方式。
・1クリック登録画面
・URL
パスワードでの非公開機能はまたいずれ。
あと、RSSの一括インポート機能が欲しい。これもまたいずれ。
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を読んだ。
リーダー(マネージャー)になるエンジニア向けの内容が多い。
以下、メモ。
ソフトウェア開発はチームスポーツである
コードを隠さない
コードや作業を隠してもいいことはない(≒ アイデア/意見を隠さない)。
適切なフィードバックをもらったほうが、結果としていい仕事ができる。
作業を隠したいという欲求は、批判に対する不安からうまれる。
途中の作業を隠すよりも、フィードバックをもらった方がいいし、フィードバックをもらうことに慣れよう。
ひとりで作業して、しょうもないことで止まったりすると、時間がもったいない。
作業を隠したほうが、失敗に対するリスクは大きくなる。
また作業を隠すとプロジェクトのバス係数も大きくなる。
プロジェクトの詳細を知っているのが自分だけなら、自分がバスに轢かれてしまったら、その時点でプロジェクトも死んでしまう。
もし他にひとりでも詳細を知っていれば、プロジェクトは(たぶん)生き残る。
このときバス係数は2倍。
チームで働くための三本柱
謙虚(Humility)・・・自分が正しいとは限らない。常に自分を改善していく。
尊敬(Respect)・・・一緒に働く人を思いやる。
信頼(Trust)・・・自分以外の人は有能で、正しいことをすると考える。そうすれば、仕事を任せることができる。
合わせて HRT と呼ぶ。ハートと読む。
コード批判について
「自分は、自分の書いたコードではない」
この言葉を自分だけきちんと認識していたところで意味は無い。
チーム共通の認識になっていなければ意味がない。
「このコードは間違っています。○○パターンを使うべきです」
→「この部分がわからないのですが、○○パターンなら読みやすくなるでしょうか」
相手への疑問でなく、自分の疑問として謙虚に聞く。
注意深く、相手を不快にさせないように。
過去の失敗をドキュメント化する
Googleでは「ポストモーテム(検死解剖)を書く」という。
謝罪ではなく「何を学んだか」「何を変更したか」を書く。
そして、みんなが読める場所に置く。ドキュメント化する。
早い段階で失敗・学習・反復しよう。
コミュニケーションの原則
同期コミュニケーションを減らし、非同期コミュニケーションを増やす。
この本ではメーリングリストを推している。自分はグループチャットがいいのではと思った。
ミッションステートメント
目指すこと・目指さないことを明確に決める。
エンジニアがひと目で理解できるように。
「価値のある会社を目指します」「株主への価値を生み出す」→全然具体的でなく意味わからないからダメ。
チーム内での認識の違いを明らかにして、プロダクトの方向性を導く。
技術的な方向性も含む。
コミュニケーション手段
・メーリングリスト(→ちょっと時代遅れと思っていたが、まだまだ現役らしい)
・オンラインチャット・・・プライベートチャットでなくグループチャットを使おう!
・バグ管理ツール・・・優先順位をつける。掲示板と同じ。衆目に晒す。
・コードコメント・・・何を書かない。なぜを書く。 →リーダブルコードあたりを読むといいかも?
・コードレビュー・・・第3者の目。
船にはキャプテンが必要
「マネージャー」ではなく「リーダー」と呼ぼう。
※ Googleではマネージャーは「部下がいる」という意味でしかないらしい。
・Googleでのリーダーの種類
TL(チームリード)・・・プロダクトの技術的方向に責任を持つ
TLM(テクニカルリードマネージャー)・・・TLに加え、チームにいるエンジニアのキャリアや幸せに責任を持つ。
マネージャーの評価軸
エンジニアの評価軸をコードのような制作物でみなすと、マネージャーの評価軸がゼロになってしまう。
ピーターの法則
「階層的な組織に属する人間は、必ずその人の無能レベルまで昇進する」
結果を出せなくなる役職まで昇進し続ける(結果が出る役職ならば昇進できる)。
採用
「Aランクの人はAランクの人を採用する。Bランクの人はCランクの人を採用する」
触媒になる
多くの場合、適切な答えを知るよりも、適切な人を知る方が価値がある。
注意散漫→自発的
エンジニアが注意散漫なら、方向性が必要。
何をすべきかを理解して、構造化スキルを身につけて、管理可能なタスクに分割する。
退屈→興奮
エンジニアが退屈しているならば、モチベーションが必要。
モチベーションは外発的動機と内発的動機の2種類ある。
外発的動機・・・金
内発的動機・・・
・自律性・・・プロダクトにオーナーシップを感じる
・熟達・・・新しいスキルを学んだり、すきるを向上させる。
・目的・・・顧客からの役に立ったメールなど
組織を操作する
悪い習慣をやめることはできない。良い習慣と置き換えなければいけない。
悪い悪いというだけでなく、代案を出して悪い習慣を良い習慣に置き換えていこう。
感想
ついついコードなどを隠しがちだが、積極的に作業を表に出すようにする。
これはオープンソースがどうという話でなく、チームとして仕事に取り組む上で、
コードを隠すとフィードバックをもらえなくなてしまって損だよ、ということ。
仕事では進捗報告が遅れがちになることもあるので、肝に命じようと思った。
リーダー(マネージャー)レベルの話が多く、自分はいまその立場にないのだが、
エンジニアのモチベーションの話などは自己分析に役立つと感じた。
エンジニアはエンジニアらしく、積極的に会社に良い習慣を植え付けていこう。
PHPのバージョン管理はphpbrewが使いやすいです
PHPのバージョンを管理するソフトウェアはphpbrewが一番使いやすいです。
なので、みなさんもphpbrewを使いましょう。
インストール方法や使い方は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
ではそれができる。
メソッドの前後に処理を(自然に?)追加できるので便利ですね!