2014-04-14

よつばとのマグカップ — アクトインディ送別会でのプレゼント 1

よつばと! マグカップ (牛・300ml)

2014-03-31 をもってアクトインディ株式会社を退職した。3/28 に会社の人達が送別会を開いて下さり、プレゼントを頂いた。そのうちの一つがマンガ「よつばと」のマグカップだった。会社でコーヒーを飲んでいたのが印象に残ったのかな?

さて、ぼくは「よつばと」を読んでいない。なぜ「よつばと」のマグカップなのか。これは、マンガも読みなさい、というお達しなのかな?

サイズは 300ml ということで、ぼくが愛用している Amazon のマグカップ (380ml) より一回り小さい。

【Amazon.co.jp限定】Amazonオリジナルマグカップ白
【Amazon.co.jp限定】Amazonオリジナルマグカップ白

今回、記事にするに当たりネットで価格を見たのだけど、これ 2,680 円もするのね! びっくり。家用に置いておこ。家ではコーヒーは飲まないけれど、サイダーを飲みながら、音楽を聴きつつ、本を読むのがぼくの至福の時の一つなので、そんな時に活躍してもらう!

素敵なマグカップをありがとう!!

2014-04-10

複数の Github アカウントを使う方法

GitHub は一人が複数のアカウントを持つことを良しとしていない。とはいえ、何らかの事情で複数のアカウントを取得する人もいると思う。例えば、個人と会社でアカウントを分けなければいけない場合など。

ここでは仮に ataka-private と ataka-work という 2 つのアカウントを取得した場合を考えてみる。

デフォールトは仕事用

仕事用アカウントで big-project リポジトリーを作成したとする。この場合、git clone/pull/push は次のようになる。

$ git clone git@github.com:ataka-work/big-project.git
$ git pull git@github.com:ataka-work/big-project.git
$ git push git@github.com:ataka-work/big-project.git

仕事用の設定は特に問題ない。ところが、同じ様に ataka-private アカウントに git でアクセスすることが出来ない。

プライベート用の設定

まず、プライベート用の ssh キーを作る。

$ ssh-keygen -C ataka@private

デフォールトでは id_rsa というファイル名になるけれど、ここは id_rsa_private という名前に変えておく。github の ataka-private アカウントに id_rsa_private.pub の中身を登録。

ataka-private アカウントにアクセスするのに、id_rsa_private を使う様、~/.ssh/config に次の設定を追加する:

Host github.com-ataka-private
  HostName github
  User git
  IdentityFile ~/.ssh/id_rsa_private

ataka-private アカウントにある misc プロジェクトを git clone してみよう。github が推奨するように remote を設定する。ただし、github が提示する URL に一つ変更を加える。

$ git remote add origin git@github.com-ataka-private:ataka-private/misc.git

これで、clone/pull/push が出来るようになる。

$ git clone git@github.com-ataka-private:ataka-private/misc.git
$ git pull origin master
$ git push origin master

アカウントの数が増えても、同様に対処していけばいいだけ。

あとがき

ここでは仕事用をデフォールトにしたけど、逆にしてしまっても良いし、.ssh/config に仕事用の設定を追加してもいい。ま、どうしても複数アカウントを作らなきゃいけない場合に参考にして頂ければ嬉しい。

ref

2014-04-02

最近の rbenv (2014-04)

rbenv を使うと複数バージョンの Ruby を入れられる。過去にも一度記事にしたけれど、最近、少し使い方が変わったのでもう一度書く。

準備

Debian 系では下記パッケージを事前にインストール。

$ sudo apt-get install build-essential libreadline-dev libssl-dev zlib1g-dev

OS X では XCode Command Line が入っていれば大丈夫... かな?

rbenv インストール

rbenv は git リポジトリーからインストールする。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

Bash の場合、設定を .profile と .bashrc のどちらに書くか難しい。.profile はログイン時のみ読み込み、.bashrc は bash 起動時に読み込み。screen で複数のスクリーンを起動する場合、.bashrc に設定を書いておかないと、新しいスクリーンで rbenv の設定が読み込まれない。

ところが、Debian 系が用意している .bashrc には非対話で呼ばれた時に、後ろの設定を無視するコードが入っている。これは sudo で呼び出した時に rbenv の設定が読み込まれず困る。よって、設定を書くなら、.bashrc の最初に書くのが良い。というのが、今のぼくの結論。

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

ruby-build のインストール

最近の ruby-build は ~/.rbenv/plugins ディレクトリー下に入れるのが主流らしい。

$ mkdir -p ~/.rbenv/plugins
$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

ruby と bundle のインストール

ruby をインストールする。

$ rbenv install -l
$ rbenv install 2.1.1
$ rbenv global 2.1.1
$ rbenv rehash

bundle もインストール。

$ rbenv exec gem install bundle --no-ri --no-rdoc

あとがき

rbenv の設定ファイルの書き方にハマったので説明を加えたのと、ruby-build のインストール方法が変わったので記事を書き直した。bundle を gem install bundle するのと rbenv exec gem install bundle するので、どう違いがあるのか実は分かっていない ^^;

2014-04-01

ChatWork に入社しました

2014-04-01 (火)、本日よりチャットワーク (ChatWork) 株式会社に入社した。チャットワーク社は「チャットワーク」というサービスを運営している。サービスとしては、Skype や LINE らと同種の「チャット」サービス。企業でも使える「使い勝手」「安心感」が本サービスの売りか。

退職前夜

前職アクトインディで iPhone アプリを開発していたことは、昨日の記事で書いた。

実を言えば、ヘッドハンティング的なお誘いは数件来ていた。でも、iPhone アプリを開発していた時のぼくは、その誘いを断っていた。iPhone アプリ開発は決して楽しいことばかりじゃなかったけど、少しずつ改良されていく手応え、整っていく開発体制、何より一から育てたアプリの成長を見るのが嬉しかった。

作っている作品の質が悪くないことは自分が分かっていた。

認知率は低かったけれど、一つきっかけさえ在れば... という思いがあった。

そして運命の 11 月。隣でサービスを開発してたエンジニアが、メールで送られた「アプリ開発中止」の知らせを教えてくれた。心に穴が開いた。

その後、何度か保守目的で iPhone アプリのソースコードをいじった。

楽しかった。

iOS アプリの開発をしたい。

思いが強くなった。

転職活動をしてみた。

数社当たったところで、仕事の方が忙しくなり転職活動はなりを潜めた。それが去年の末のこと。

ChatWork との出会い

1 月に入って、ChatWork から連絡が入った。昨年末に面接を受けた結果だった。

驚いたことに面接に受かっていた。

次は二次。

ChatWork では二日間の体験入社を経てスキルと人柄とのマッチングを見る。初日午前中はセッティングや会社概要の説明ビデオ。そしてランチ。ゲストは食事が食べられない、と恐れられるランチ。エンジニア陣に囲まれて質問を受けながら食事を食べる。この時、用意されたお弁当を間違えて取ってしまったのはここだけの話。内容は、現職 (アクトインディ)、前職 (JVC ケンウッド) に及び、Emacs 使い・Dvorak 配列・T-Code と脇道に逸れたり、組み込み系のプログラミングの話に喰いつく人があったり、とこちらも随分楽しむランチとなった。もちろん、お弁当も完食。

午後からはプログラミング実習。課題を出されて、コーディングをする。そのリポジトリー名を見てひっくり返った。「deep-dive」。深く潜る者。

ぼくは...何をした? ランチでとてつもなくハードルを高くしてしまったらしい。

社内の雰囲気は良かったけれど、外は危険な天気となっていった。

いや、マジで。

体験入社二日目は 2014-02-14 (金)。あの東京大降雪の日。ChatWork に向かって電車に乗ったところ、一駅も進まない内に電話が鳴った。

「今日の体験入社はリモート作業でお願いします」

ですよね〜。

雪のおかげで、お昼に出かけるのも大変だったし、自作プログラムのプレゼンテーション時間が早まったりしたしで困った。今だから言うけれど、プレゼンが終わった後、落ちたと思ってほうけてた。「YES」という答えが信じられなかった。

最終面接を経て、ChatWork への転職が決まった。

あとがき

体験入社二日間。これはとても面白い試みだった。実際に社内に入って、仕事をしている姿を見せる・見る。ぼくもこれならば... と思えた。ChatWork もぼくを採ってくれた。

今、自分の実力を見るに、まだ経験値が低い。ちょっと作りたいアプリもあることだし、自作アプリも作って経験を増やしたい。願わくば、人がワクワクできるアプリを会社でも個人でも作っていきたい。

アクトインディの面白制度

2014-03-31 (月) をもってアクトインディ株式会社を退職した。半年で社員数が 3 倍に増える激動の一年を過ごせたことをありがたく思う。

さて、アクトインディで残念だと思ったことがある。それは、自分達のマーケティングが下手なこと。例えば、エンジニアの募集をする。募集要項を書く。その募集要項が他社と比べて魅力的に見えない。拙い筆ではあるけれど、アクトインディの面白い制度・便利な制度を紹介するとともに、ぼく自身のコメントも加えてみたい。

エンジニア向け制度

自宅勤務 (リモート作業) 制度

週に最大 2 回、自宅で作業できる制度。周りとの連携を考えて、大抵その週の初めに申請を行なう。もちろん、会社に出る方が効率の良い場合は、自宅勤務する権利を使わなくても良い。

ぼくは、この制度を少し変型させて、ゴールデン・ウィークに利用させてもらったりもした。お蔭で、普通の人より長期の帰省をすることができた。帰省先でも仕事が出来る仕組みは有難いものだった。

リモート作業については、過去に一つ記事を書いているので、そちらも参照して欲しい。

ちなみに、現在はママさんデザイナーが一人社員に居て、その方は週 4 程の自宅勤務をしている。

最新の Ruby と Rails

サービスの開発は Ruby on Rails を使っている。この場合、Rails が枯れてきてからアップデートする派と、常に最新を追っている派に別れる。アクトインディは後者で、Ruby も一早く 2.0 を採用したし、今は 2.1 系に移行している。Rails も 4.1 系へ移行が進んでいる。

チケット駆動開発

Redmine にチケットを登録し、マイルストーンを管理している。

Redmine を使うと、どうしても「ウォッチャー」のメールが大量に飛ぶことになるけど、その解決策をぼくは見出せなかった。とはいえ、「チケットにない作業は闇作業」という文化は根づいているので、混乱は小さい。編集・営業・デザイナーといった人達も Redmine を使ってチケット起票してくれる文化が育っている ((プログラマーだけしか Redmine を使っていないのと、周りの人達全員が Redmine を使っているのとでは、随分と作業効率違うよね)。

テスト・ファースト

テスト駆動開発を採用している。

シナリオ系のテストは少ないかな? モデル系のテストはほぼ書いている。

Github フローとレビュー

チケットに対して 1 つのトピック・ブランチが作られ、trunk ブランチに取り込まれる際にレビューを受ける仕組みが出来ている。

これは最初のトライ。レビューはほぼほぼ良い感じに動いている。レビューを取り入れが前までは git flow を使っていたけれど、今は Github フローに変えようか... と移行作業中。

技術書購入

月三万円までエンジニアで技術書を購入できる。

この制度は、デザイナーさんも含んでいるのかな? ちょっと覚えていないや。

出勤時間の自由化

一応、コア・タイムはある。でも、コア・タイムは短め (10:00-15:00 だったかな?) で、8 時間働けるなら何時に出社しても構わない。ただし、事前に「何時に出社する」という約束をする必要はある。フレックス制度というよりも、社員一人一人に対して会社が出社時間の契約をしている感じ。

ぼくは、朝 7 時出社の 16 時退社で働いていた。会社から家まで遠いのと、田園都市線の (有名な) 混雑を避けるのを考えたら、出社時間がこんなになってしまった。朝型のぼくにはありがたい制度だった。もちろん、会社では一番出社。何故か掃除のおじさんと仲良くなってしまった。

定時退社する日に限って、帰りの電車の遅延に巻き込まれるジンクスあり。ちょっち涙。

リスペクト手当て

4 か月に一回、尊敬・感謝の言葉を伝える制度。ネガティブなことは書かないのがルール。コメントは匿名で対象者に知らされる。

言葉を伝えると伴にポイントも渡せる。持ちポイントは 1 人 100 ポイント。1 人に 100 ポイント上げても良いし、適当に配分しても構わない。ポイントに対してその期の業積に応じた手当給が付く。

部門間を越えた 360 度評価と言っても良いかもしれない。

人数が 10 人前後だった時は、とても良い制度だった。考えるコメントの数も 10 個で良かったし (書く書かないは個人の自由)、ポイント配分も楽だった。100 ポイントを 10 で割れば 10 ポイント。特にお世話になった人に 20 ポイント、その他の人は 5 ポイント... という風に傾斜を付け易かった。

人数が 30 人に増えると大変。30 人分のコメントを書くのは一仕事。コメントする言葉が見つからない人も出てきてしまった。そもそも仕事で絡まないと、リスペクトも何もない。ポイントも 100 ポイントを 30 で割ると 1 人頭 3 ポイント。傾斜を付けつつ、全員にポイントを上げようとすると、1 ポイントしか上げられない人とか出てきちゃった。

それでも、この制度。ポイントはなくても良いから、メッセージだけでも貰いたい・あげたい、という程人気だったりする。ぼく自身、部門を越えたメッセージをもらうと元気が出た。なくならないで欲しい制度だけど、一工夫必要な仕組みだとぼくは思っている。

お墓参り手当

アクトインディでは先祖・先達への感謝を大事にしている。墓参りもその一つ。

最近、墓参りに行く若者が減ってきたということもあり、こういう制度は面白いと思う。基本、自己申告制だけど、多くの人は、墓参りの様子を Yammer などに投稿している。そこから、墓参りの地方による違いなどに話題が広がったことも。

カフェ手当

作業環境を変えたい人向けの制度。忘れられた制度。

新しいオフィスになって、一人で立ち作業できるオシャレな空間が用意された。作業環境を変えたい人は、カフェなどに行かず、スタンディング・テーブルで作業している。

あとがき

以上、アクトインディの面白制度を紹介してみた。同じ制度を導入している会社もあると思うけど、こんな制度もあるのか。うちも取り入れてみようかな? なんて考えてくれたなら嬉しい。

2014-03-31

アクトインディ株式会社を退職しました

2014-03-31 (月) をもって、アクトインディ株式会社を退職する。最終出社日は 3/28 (土)。

入社から 1 年 1 か月。短いようで、激動の 1 年だった。少し振り返ってみたい。

ぼくの経験した 1 年間

2013 年 3 月の入社時点。アクトインディの東京オフィスは 10 人程度のメンバー構成だった。

当時のエンジニアはぼくsi除いて 2 人。うち一人は、ぼくの入社と交替するように退職した。また、ぼくの入社から 2 日遅れで新しいエンジニアが入った。結果、3 人のエンジニア体制が半年ほど続く。

5 月、大きな変化が訪れた。メイン・サービスである 子供とお出かけ情報「いこーよ」 を大きく成長させることになった。サービス拡大のために人材を積極的に採用し始めた。人が増えたことでオフィスが手狭になった。そして、新オフィスへ引越をした。5 月半ばのことだった。前オフィスと比べて 3 倍くらい広いように感じた。

積極的な人材採用は 11 月頃まで続いた。結果、社員数は 10 人ちょっとから 30 人近くに膨れ上がった。ほぼ半年で 3 倍の社員数になった。ママさんを主体とする「ママさんチーム」が生まれた。紙媒体で活躍していた人達を採用して、「編集部」が発足した。デザイナーも 1 人から 4 人に増えた。エンジニアも 3 人から 6 人に増えた。ディレクターも採用され、「開発」の組織化が進んだ。

オフィスの引越と、急激な社員数増化という「変化」の中に居られたのは、とても貴重な経験だった。

エンジニアとして...

ぼくは 4〜11 月の間 iPhone アプリの開発担当者として働いた。最初のバージョン 1.0 はリリースが遅れて 8/21 だった。その後数回のバージョン・アップを繰り返し、バージョン 1.1.2 が 11/15 にリリースされた。

この開発で一番大変だった出来事は、iOS 7 のリリースだった。ぼくはネイティブ Objective-C で開発していたけれども、様々な変化にとまどった。対応に手こずった。iOS 6 と iOS 7 の両方をサポートするのは大変だった。デザイナーには iOS 7 の「新コンセプト」の説明が必要だった。そのために Yahoo! の勉強会に参加し、スライドを作った。

このスライドを SlideShare にアップしたところ、それなりの反響があったので嬉しかった。

バージョン 1.1.2 を最後に iPhone アプリの開発がストップ。ぼくは いこーよ (Ruby on Rails) の開発に移った。

いこーよの開発において、Ruby on Rails だけでなく、Chef や VirtualBox, Vagrant, Nginx, AWS などに触れることが出来たのは楽しかった。

また営業やママさんチーム、経理の方などから PC の使い方について質問を受け付けるのもエンジニアの役目だった。セキュリティ・ソフトのアップデートに失敗するといったものから、ファイル・サーバーに繋がらない、無線 LAN の調子が悪いといった幅広いリクエストの受け口になった。一つ解決して「ありがとう」と言われるのは、嬉しいものだった。

そして、退職...

iPhone アプリの開発が止まって心に穴が開いた。保守案件で iPhone アプリのソースコードを触る時、楽しかった。iPhone アプリの開発を続けたいという要求が強くなった。

幸運にも、お互いのニーズがマッチする会社と出会えたので、転職する。転職先については、また改めて記事にしたい。

2014-02-10

Ubuntu ですぐに画面ロックする

Ubuntu 12.10 を使っている。諸事情で、離席時にはパスワード入力するよう求められるようになった。最初、サスペンドするコマンドとサスペンドから復帰する時にパスワードを求める設定を加えようと思ったけど、画面ロックする方が楽と分かったので方針を転換した。

画面ロックから戻る時に、パスワード入力を求めるようにする設定は簡単なので省略。

Gnome を使っているなら、次の実行ファイルを path のある場所に置く。ぼくは ~/bin/lock という名前にした。実行権限を与えるのを忘れずに。

#!/bin/sh
lock='gnome-screensaver-command -l'
$lock

これで lock コマンド一つで画面ロックがかかる。コマンド名を l だけにしようかと思ったけど、タイポした時悲惨そうなので止めた。

サスペンドと違って画面ロックは管理者権限が要らない。sudo なしで実行できるのは安全かつ楽。

ちなみに、

  • Ctrl + Alt + L

で画面ロックをかけることができる。ぼくは... このキーバインドを Emacs でいつか潰しそうな気がしたので、lock コマンドを作った。このエントリーを書きながら、何度か試したけど、Ctrl + Alt + L の方が便利かもしれない。

2014-02-06

Emacs の TRAMP を使って他のサーバーにアクセスする

最近、Emacs の TRAMP にお世話になっているのでまとめておく。

Tramp は Emacs からリモート環境 (リモート・サーバー) にアクセスする機能・パッケージ。Emacs 22 からデフォールトに含まれた。使い方はファイル・オープンの延長。

remote サーバーのファイルを開く

設定は必要ない。

  • アクセス方法: ssh
  • ユーザー: foo
  • サーバー: bar.com
  • ファイル: /home/foo/.bashrc

上記のファイルを編集する場合。C-x C-f (M-x find-file) から、次の様に入力する:

Fird file:  /ssh:foo@bar.com:/home/foo/.bashrc

これでパスフレーズが聞かれる。authorized_keys をちゃんと設定していれば、パスフレーズ入力なしでファイルを開ける。

ssh の前に / を置くのがポイント。あとは、ssh でログインしている人にはおなじみかな。

ぼくは直接ファイルを開かず、Dired を起動している。

Fird file:  /ssh:foo@bar.com:/home/foo/

こっちの方が、サーバーの中で動き易いから。

TRAMP を使うと、サーバーに Emacs が入っていなくっても問題ないし、サーバーに -X オプション付きで ssh ログインする必要もないし、ssh でログインしてターミナル版 Emacs で作業する必要もない。便利!

2014-02-05

Google Analytics の管理権限を委譲する方法

Google Analytics で複数の人に「レポート」を共有する方法は色々な所で書かれている。ところが、他人に「レポート」の管理権限を渡す話となるとあまり話題に上がっていない。せっかくなので、メモ程度にまとめてみる。

Analytics について知る

まず、Google Analytics にログインして管理権限を移したいレポートを開いてみる。

右上に「アナリティクス設定」というボタンがあるのでクリック。次の様な画面へ現れる。

管理の下が 3 つのカラムに分かれている。左から「アカウント」「プロパティ」「ビュー」。各々のカラムに「ユーザー管理」の項目がある。他人に管理権限を渡すには「アカウント」の「ユーザー管理」をいじる必要がある (赤色で囲った所ね)。

ポイント

  • 「アカウント」カラムは Google Analytics へのログイン・アカウント (普通 Gmail アカウント) とは違う!
  • 管理者権限の委譲は「アカウント」からでしか行なえない。プロパティやビューの管理者権限だけ移すことは出来ない!!

委譲作業

やり方は簡単。他人を追加して、自分を消すだけ。

  1. アカウントのユーザー管理を選択
  2. 委譲先のユーザーを追加・権限付与
  3. 自分のユーザーを削除

自分を削除した時にエラーが出る。もう閲覧権もないページにアクセスすることになるんだから当然だよね。ホーム・ボタンを押せば元に戻れる。

与える権限は、「ユーザー管理」「編集」「共有設定」「表示と分析」の 4 種類ある。よく分かっていないので、全部与えた。

以上の作業を終えると、ホーム画面から先ほど消した「アカウント」がなくなっているのが確認できるはず。そして、委譲された人は、その「アカウント」を我が物として使うことができるようになっている。委譲作業終了。なお、自分のユーザーを自分で消さず、委譲先の人に消してもらう手もある (試してないけど、大丈夫なはず)。

注意

アカウント・レベルで全ての権限を他人に与えていると、他人に自分のユーザー権限を奪われる可能性がある。「ユーザー管理」にはお気を付けあれ。

2014-01-17

Objective-C の NSMutableArray の簡単な作り方

Objective-C ではサイズを変更できない配列 (NSArray) と、サイズを変更できる配列 (NSMutableArray) がある。Objective-C の参考書を読むと、Array の作り方として次のようなコードが書いてある。

NSArray* array = [[NSArray alloc] init];
NSMutableArray* mutableArray = [[NSMutableArray alloc] init];

これは本当に初歩的な書き方。Objective-C 2.0 (今の iOS 開発なら、Objective-C 2.0 がデフォールトになってる) なら、もっと簡単な Array の作り方がある。

NSArray* array = @[];

Array は大きさを変えられないので、実際のコードでは次の様にデータを入れて初期化する。

NSArray* array = @[@"foo" @"bar" @"hoge"];

Array はこんなにシンプルな書き方があるのに、MutableArray にはないものか... と諦めていたら、簡単な方法を見つけた。mutableCopy を使う。

NSMutableArray* mutableArray = [@[] mutableCopy];

Array を作って mutableCopy で mutable 化する。なんとシンプルな!!

蛇足ながら初期値を持つ場合のコードは...

NSMutableArray* mutableArray = [@[@"foo" @"bar" @"hoge"] mutableCopy];

NSMutableArray はサイズ 0 のものを作って、アイテムを push していくからあまり使わないけどね。でも、シンプルな NSMutableArray の作り方は覚えておいて損はない。