Rubellum fly light

ほぼPHP日記

Kitematic (Beta) 2.app は壊れているため開けません。

Docker for Mac をインストール後、メニューにkitematicの文字が。

早速、kitematicをダウンロード&起動すると、以下のエラーが発生。

f:id:rubellum:20160915194508p:plain

Kitematic (Beta) 2.app は壊れているため開けません。 ゴミ箱に入れる必要があります。

どうやらAppの形式が古いかららしい。

以下のコマンドを実行ファイルに適用すると開けるようになる。

$ xattr -rc Kitematic\ \(Beta\).app

f:id:rubellum:20160915194505p:plain

このコマンドがなにをするものかは調べていない。

参考

http://qiita.com/quattro_4/items/f5b56c1897c0cc235c0f

http://apple.stackexchange.com/questions/58050/damaged-and-cant-be-open-app-error-message

なお、kitematicの画面が文字化けしていて、結局使えなかった。かなc。

「PHP RFC」でググってPHPの未来に思いを馳せる

RFCで公開されていた「pipe-operator」がF#っぽくて素敵でした。 見た目が奇抜すぎるので、仮に実装されたとしてもなかなか使えないような気も…。

PHP: rfc:pipe-operator

# PSR7 Example

 $request = getGlobals()
   |> parseRequest($$)
   |> buildPsr7Request($$);

PHPの開発がどういう風に進められているのかよく知らないのですが、 いつの日か実装されるんですかね…?

自分はPHPが大好きなので、 たくさんの機能が実装されるととても嬉しいです。

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クリック登録画面

f:id:rubellum:20150215132315p:plain

・URL

f:id:rubellum:20150215132319p:plain

パスワードでの非公開機能はまたいずれ。

あと、RSSの一括インポート機能が欲しい。これもまたいずれ。

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

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

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

f:id:rubellum:20150213085124p:plain

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

高速化というか、操作でストレスがたまらないようにするために、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種類ある。

 

外発的動機・・・金

内発的動機・・・

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

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

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

 

組織を操作する

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

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

 

感想

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

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

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

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

 

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

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

 

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