リモートワーク

Rebuild: 32: How We Work Remotely (Naoya Ito) この回で 37signals(現:Basecamp)と GitHub を中心にリモートワークについて話がありました。 自分もここ2年ほどリモートワーク中心で過ごしてきたので色々と思うところがありました。 その前に紹介されていた 37signals の下記の書籍を読んでからブログに書こうと思ったのでした。 強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 ということで読み終わったので、自分の経験交えていくつかの点について述べたいと思います。 上記の本の感想として概ね同意できるところですが、これは難しいという部分もありました。あまり書くとネタバレになってしまうので、一つあげると、グローバルに渡って雇用する際に法的な壁があったら個人事業主で雇えばよいと書かれていましたが、これをさらっと言うのは社会保険が整っている日本では厳しいと思いました。 それでは色々な視点でリモートワークについてつらつらと書いてみます。 なぜリモートワークなのか まず背景として、自分がフリーランスエンジニアになってから数年常駐お世話になっていた会社と、今は持ち帰りで一緒に仕事をさせてもらっています。 一番の要因は3年前の震災の影響で都心へ通勤することの諸々リスクを身をもって知り、それをなるべく低くしたいと考えたからです。またフリーランスとして自分でアプリ製作の時間などを必要としていたこともあります。 移動(通勤)が無くなることについて メリット 往復3時間の移動(通勤)時間が消え、平日の寝不足も無くなりましたし、休日の寝溜めも不要になりました。台風や大雪の影響も受けなくなりました。家事含めて時間も有意義に使えるようになりましたし、総じてやれる量が増えました。 デメリット 移動が無くなったことで絶対的に歩く量が減りました。だから昼食は少し遠めの店まで食べに行ったり、わざと回り道をして帰ったりしてます。ただ散歩自体はリフレッシュにもなります。 あと移動時間にわりと小説を読んでいたのですが、めっきり読まなくなりました。習慣にもよりますが時間を捻出しないとできないです。 コラボレーション・コミュニケーション コラボレーション・タスク管理ツール リモートワークに限らず昨今の仕事には必須のツールですが、特に隣が見えない分、アクションや成果のログの共有が非常に重要になります。このツールの使い方を改善していくことが全体的なチームの向上に繋がるでしょう。ただこういったツールを3つ以上導入するのは止めた方が懸命です。追えるのはせいぜい2つが限界です。 メッセンジャー・チャットツール 仕事上必須なのはもちろんですが、雑談部屋やカテゴリごとの部屋があると、ちょっとした話題の共有や問題に直面したときの相談ができて良いです。あまり得意ではないですが、顔文字・絵文字も上手く使ってテンションの共有もうまくしたいところです。これは本の中でも触れられています。 音声・動画通話 話した方が早いことや感情も伴う伝達を必要とするときはテキストチャットではなくボイス・ビデオチャットを行った方が良いです。ただそのままダラダラだべってしまってもお互い時間を潰してしまうので、終わるときはさくっと切り上げることも大切です。 マイクやスピーカーの良さつまり音質、そして高速なネットワークが重要です。聞きづらく無駄な集中が必要になったり自然に話せないと逆効果になります。 オフィスで相手の席に行ったり自席に来てもらって相談するというシーン。これは結局二人でディスプレイを眺めて話すことが多いので、動画で画面共有+音声で違和感なくこなせます。 ふとオフになったとき孤独感に苛まれることがあります。相手側の状況にもよりますが、長時間音声を繋ぎっ放しにしてもらうのと良いです。お互いに気にせずちょっと席を離れるときでも告げたりしない。ただ繋いでおくと向う側の雑談やキーボードタッチ音が聞こえてくるだけですが、一体感が出ます。 仕事の進め方について モチベーションの波を吸収する 1日単位での定時間は向かないでしょう。人間乗らないときはありますし、家だと逃げ道があるので、進まないときがあるのも現実です。だから平均して8時間やるのをルールとして、2日で6時間と10時間でトータル16時間という方が効果が出ると思います。もし部分的にリモートワークを導入するなら、2日間セットでやると良いと考えます。 サボりとオーバーワーク 自分は社員ではないので給与ではなく報酬を請求する立場です。だから根底にやらないと収入が無くなるという意識があります。ただ結局は成果の把握が重要になります。前述したコラボレーション・タスク管理ツールを上手く使ってより可視化することで作業量をマネージメントすることが重要でしょう。 セキュリティリスク 諸々のセキュリティリスクについては、某事件のようにインターネットに接続してる以上オフィス内であっても完全防御することはできません。単に抑え込むのではなくて各人の知識を向上させて、仕事をしづらくせずに有用なツールを適切に使うことだと思います。 リモートワークは万人に可能なのか 性格的に向かない人 思いや考えを内に溜めこむ性格の人は、外から全く見えなくなるので、マネージメントする立場の人は辛いと思います。こまめに通話や会って話す機会が必要になると思います。 いきなりリモートで始める 全く知らない人同士でいきなり始めるのは難しいかもしれません。特に文面から伝わる温度と実際のその人の抱いている感情の温度が乖離しやすい人は、ある程度対面で仕事をしたことがないと全体に悪影響になるかもしれません。 リモートワークを導入すべきか ディザスタリカバリの観点 事業のDRの観点からもリモートワークの導入はリスク回避の手法になります。現実的に震災や最近の水害・雪害の大きさを考えると、日本では事業的に可能な限り導入すべきだと思います。 優秀な人材を確保できなくなる リモートワークがこなせる人は結局のところ、従来の働き方における障壁があっても、それを上手く利用して成果が出せる人になります。そうなると唯一平等に与えれた時間を有効利用できるため、優秀な人ほどそういった環境を望むようになると思います。そのためリモートワークを導入せざるえない時が近づいていると思います。 なかなかまとまらず1週間以上下書きだったのですが、とりあえず書き終わったので公開します。

2014年3月11日 · Toshimitsu Takahashi

S3バケットにローテーションしてバックアップする serverbackup-s3

さくら VPS サーバをいくつか借りていて、ホストの設定ファイルやデータべ―スダンプなどのバックアップを AWS S3 に置いています。S3 へのアップロードは無料なので、それなりに大きなファイルを毎日バックアップしても心配する必要はありません。 元々個別にスクリプト書いて、tar.gz したアーカイブファイルを s3sync で同期していました。その後仕組みをある程度まとめて Gitlab で内部管理していたんですが、デプロイキーの扱いが面倒だったため、今回 GitHub に上げました。 serverbackup-s3 tilfin/serverbackup-s3 · GitHub 特徴 バックアップファイルのローテーション 複数の S3 バケットに日毎に振り分けられる。例えば、奇数日は東京、偶数日はシンガポールのバケットへということが可能。 バックアップスクリプトをサービスごとに分けて管理できる。 使い方 s3sync & serverbackup-s3 のインストール s3sync は開発が止まっていて、Ruby 1.9 以降に未対応だったり、etc ディレクトリの位置がアレだったりするのですが、その辺を修正した私のフォークしたリポジトリを使うと簡単です。 以下の例では、/backup の下にバックアップ処理をまとめます。 $ sudo -i # mkdir /backup # cd /backup # mkdir log # mkdir tmp # git clone --depth 1 https://github.com/tilfin/s3sync.git # git clone --depth 1 https://github.com/tilfin/serverbackup-s3.git s3sync の設定 # cd /backup/s3sync/etc # vi etc/s3config.yml s3config.yml に AWS のアクセスキーとシークレットキーをセットします。 ...

2014年2月27日 · Toshimitsu Takahashi

Ubuntu で Nginx のキャッシュヒット率を Munin でモニタリング

Nginx をリバースプロキシとして利用していて、さらにキャッシュ設定をしています。実際どれくらいプロキシキャッシュの効果があるのが、Munin で集計して監視してみる設定方法です。 前回は Nginx 自体の状態を監視設定してみました。 Ubuntu で Nginx のステータスを Munin でモニタリング - tilfin’s note この続きです。 munin-monitoring Munin はいくつかのプラグインを apt-get で入れると追加されてますが、さらにサードパーティ製のプラグインは GitHub で管理されています。 munin-monitoring/contrib · GitHub Rootユーザで今回は /usr/local/munin にリポジトリをクローンします。 $ sudo mkdir /usr/local/munin $ cd !$ $ sudo git clone https://github.com/munin-monitoring/contrib.git nginx-cache-hit-rate リクエストのキャッシュヒット率などを集計するプラグインになります。これを利用します。 nginx-cache-hit-rate スクリプトは contrib/plugins/nginx/nginx-cache-hit-rate に入っています。 nginx-cache-hit-rate スクリプトをプラグインディレクトリにシンボリックリンクします。 $ cd /etc/munin/plugins/ $ sudo ln -s /usr/local/munin/contrib/plugins/nginx/nginx-cache-hit-rate このスクリプトは Perl 製でモジュール File::ReadBackwards.pm が必要になります。 CPAN と File::ReadBackwards モジュールのインストール 設定中のさくら VPS の Ubuntu 12.04 には入っていないため、CPAN からインストールします。 Rootで cpan を実行します。未設定の場合はインタラクティブに初期設定を行います。終了後 cpan のシェルになるため、install コマンドで File::ReadBackwards.pm をインストールします。 ...

2014年2月9日 · Toshimitsu Takahashi

Ubuntu で Nginx のステータスを Munin でモニタリング

さくら VPS の Ubuntu 12.04 LTS を入れたホストで Munin による Nginx の監視を始めたので設定方法をメモしておく。 Node サービスのみセットアップ。 $ sudo apt-get install munin-node Nginx - stub_status 設定 Nginx には指定したパスを HTTP 叩くと自身の状況をレポートしてくれる HttpStubStatusModule がある。これは Ubuntu 12.04 で apt-get install nginx すると標準で付いている。 stub_status ディレクティブは、 nginx.conf 等のどこかに /nginx_status パスで stub_status が返るように設定する。サーバ内からのアクセスだけ許可するようにも設定しておく。 server { listen 80; server_name localhost; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } } 設定したらリロードして試しに叩いて確認しておく。 $ sudo /etc/init.d/nginx reload $ wget -q -O - http://localhost/nginx_status Active connections: 1 server accepts handled requests 2214 2214 5846 Reading: 0 Writing: 1 Waiting: 0 Munin の Nginx プラグインを設定 標準で入っている nginx_request と nginx_status を設定しました。 plugins ディレクトリにプラグインスクリプトのシンボリックリンクを張ります。 ...

2014年2月8日 · Toshimitsu Takahashi

Xcode 5 で既存プロジェクトを XCTest に乗り換えるときに嵌ったこと

すんなりできたこと テスト用ターゲットの Link Binaries With Libraries で SenTestingKit.frameworkを外して、XCTest.frameworkを追加した。 既存のテストを Edit → Refactor → Convert to XCTest… でコンバートした。 嵌ったこと テストケースが実行されない。 Build Phase の Wrapper Extension を xctest に変更する。 Library not loaded: 〜 エラーになる。 iOS シミュレータを iOS 6.1 にしていた(7 にする)。

2014年1月29日 · Toshimitsu Takahashi

GitHub に公開した Node.js スクリプトに Travis CI を導入し Coveralls でカバレッジ管理するまで

GitHub に httpreqtest という Node.js で動くクライアントのHTTPリクエスト内容を JSON でそのまま返すスクリプトを公開した。非公開のトリッキーな仕様の API サービスに対して、クライアントを作るにあたり、実装チェックする必要があり勢いで作った。 このリポジトリ tilfin/httpreqtest · GitHub に build pass と coverage バッジを付けたいと思い、Travis CI を導入しテストを走らせ、Coveralls でコードのカバレッジが表示できるようにしたので、それをメモしておく。 テスト まずテストがなければ始まらないので、Mocha と SuperTest を使ってテストを書いた。 mocha と supertest を npm でインストールし、package.json の devDependencies に保存する。 $ npm install mocha –save-dev test ディレクトリを掘り、その中にテストコードを書いた jsファイルを置く。 package.json の scripts には { “test”: “mocha” } と記述して、npm test で実行されるようになる。 Travis CI ブラウザから Travis CI に GitHub アカウントでサインインする。リポジトリ一覧から当該のものをオンにする。これだけ諸々の設定が済みます。 あと、Git リポジトリのルートに .travis.yml を置きます。 .travis.yml language: node_js node_js: - "0.10" 上記をコミットしてプッシュして、Travis CI をブラウザで開いていると、ビルドおよびテストが実行されます。正常に終了すれば念願の build pass バッジになります。これを README.md に追加しておきましょう。 ...

2013年12月3日 · Toshimitsu Takahashi

Windows Home Server V1 の HDD のエラーから交換で復旧するまでのまとめ

NAS として Acer Aspire easyStore H340 を使いこんでいるのだが、その中の HDD 一つでエラーが出たので、普及するまでをまとめた。 ほぼ全てのデータを複製化して 1TB, 1TB, 2TB, 2TB の4本のHDDでドライブエクステンダーを構成しています。 このうち一本の 2TB がエラーとなっていくつかのファイルを共有フォルダからアクセスできなくなっており、 そのドライブに対して、chkdsk を下記を参考に行いました。 [FAQ]WHSのエラー時にすべてのHDDにCHKDSKを実施する方法 結果は一旦復旧して壊れているというファイルにもアクセスできたものの、再起動したらさらにインデックスが壊れたのいわれイベントビューワが真っ赤になるボロボロの状態になりました。 正直、物理的に壊れたというよりも論理的に DE なり NTFS がおかしくなっているような雰囲気でした。 そこで一旦このドライブを外しことにしました。しかし、エラーが邪魔して WHS コンソールから外すことができませんでした。そこで電源オフにして該当ドライブを外して、再度起動しました。 上記のようにハードディスクが見つからない状態で削除を選択します。 この状態で相当時間がかかります。このドライブが保持していたファイルの複製を維持するために、複製ファイルの対があるドライブから保持していないドライブにコピーしているようです。 完了はしましたが、2TB のディスクを外したことで使用容量が足りないため、すべての複製を維持することができず、複製化のエラーが別のPCの常駐アプリに通知されていました。 ここまで来れば後は通常の増設と同様です。新しいハードディスクをスロットに差し込み、認識されたら記憶領域プールに追加します。 この状態で DE のプロセスがバックグランドで未複製状態のファイルを新しいディスク領域にコピーし始めます。 上記の状態でとりあえず DE が落ち着きました。共有ファイル・フォルダの復旧完了です。 コンピュータとバックアップを使っていた場合は、バックアップデータベースにエラーが出る場合があります。その場合は、WHS コンソールの設定を開き、[バックアップ] の「バックアップのクリーンアップとデータベースの修復」で [修復] ボタンでデータベースを修復を実行します。 バックアップデータは複製化されないため、外したディスクにバックアップが含まれていた対象ホストはタイミングですべてのバックアップデータを失う可能性があります。 ポイント ハードディスクエラーで通常の操作で復旧が不可能な場合は、電源オフ状態で物理的に外す。

2013年11月27日 · Toshimitsu Takahashi

iOS 7 設定画面の色定義まとめ

グループテーブルビューなどで使うことがあるので、iOS 7 設定画面の各種パーツの色定義をまとめた。 セル 背景 #FFFFFF 1 [UIColor colorWithRed:1.0 green:1.0 blue:1.0 alpha:1.0] テキスト #000000 1 [UIColor colorWithRed:0.0 green:0.0 blue:0.0 alpha:1.0] 詳細テキスト #8E8E93 1 [UIColor colorWithRed:0.556 green:0.556 blue:0.576 alpha:1.0] ディスクロージャ #C7C7CC 1 [UIColor colorWithRed:0.78 green:0.78 blue:0.8 alpha:1.0] ボタン #007AFF 1 [UIColor colorWithRed:0.0 green:0.478 blue:1.0 alpha:1.0] 強調ボタン #FF3B30 1 [UIColor colorWithRed:1.0 green:0.231 blue:0.188 alpha:1.0] セクションヘッダ・フッタ テキスト #6D6D72 1 [UIColor colorWithRed:0.427 green:0.427 blue:0.447 alpha:1.0] 背景 #EFEFF4 1 [UIColor colorWithRed:0.937 green:0.937 blue:0.956 alpha:1.0]

2013年11月22日 · Toshimitsu Takahashi

Chrome 拡張のリッチ通知で外部サイトのイメージを表示するには

最新の Windows (ChromeOS も) 版 Chrome で webkitNotifications.createHTMLNotification メソッドが非対応になってしまった。 代わりにリッチ通知という、いくつかのテンプレートに従って表現できるデスクトップ通知が追加された。 Google Chrome 28提供開始。リッチ通知に対応(Windows)、Blinkエンジン採用 - Engadget Japanese 「Google Chrome 28」の安定版リリース Blink採用と「リッチ通知」機能(Windowsのみ) - ITmedia ニュース ただ、このリッチ通知、CSP が厳しくなってしまい、外部サイトのイメージを簡単に表示できなくなった。回避するには、Ajax で取得してローカルに保存してパスを渡すか、data URI で指定する必要がある。 ここでは後者の方法で実装した例をメモしておく。HTML5 ではその辺を Blob オブジェクトによってわりと簡単に実装できる。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 var notOpt = { type: "basic", title: "タイトル", message: "メッセージ" }; var xhr = new XMLHttpRequest(); xhr.open("GET", "<イメージURL>"); xhr.responseType = "blob"; xhr.onload = function(){ var blob = this.response; notOpt.iconUrl = window.URL.createObjectURL(blob); chrome.notifications.create("", notOpt, function(notId){}); }; xhr.send(null); 画像を responseType を blob として XMLHttpRequest で取得すると、レスポンス自体が既に Blob オブジェクトになっている。 あとは、createObjectURL で data URI 化して渡してあげれば良い。

2013年8月2日 · Toshimitsu Takahashi

Ubuntu 12.04 への HTTPS およびサブディレクトリでの GitLab セットアップメモ

設定した環境 フロントの Nginx は https である。 URL は<ドメイン>/gitlab で受ける. さくらの VPS Ruby 1.9, MySQL で Redmine 2.3 が既に動いている。 gitユーザを追加 $ sudo adduser --disabled-login --gecos 'GitLab' git GitLab shell のセットアップ インストール $ sudo -u git -i $ cd /home/git $ git clone https://github.com/gitlabhq/gitlab-shell.git $ cd gitlab-shell $ git checkout v1.5.0 $ cp config.yml.example config.yml ※バージョンは最新のものにチェックアウト 設定 config.yml config.yml の gitlab_url を外から見えるURLに変更する。 gitlab_url: “https://<ドメイン>/gitlab/” ライブラリのインストール $ sudo apt-get install libicu-dev $ sudo gem install charlock_holmes --version '0.6.9.4' データベースのセットアップ MySQL を使う https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/databases.md に従う。 ※gitlab ユーザのパスワードを控える。 ...

2013年6月19日 · Toshimitsu Takahashi