子供が生まれてもうすぐ 1 年経つので育児についてやったことをまとめてみる

久々の投稿です。二年以上書いてなかったのか。反省。

本記事は Sansan Advent Calendar の 10 日目の記事です。

概要

今年の 1/24 に子供が生まれました。第一子。男の子。

子供はめちゃくちゃかわいい

めっちゃかわいい。 プライバシーの問題があるので写真は上げませんが、すごく可愛いです。

夜泣きとかなんで泣いてるかわからないとかいっぱいあるけど、かわいいからなんとかなる。

でも育児は大変

で、1年弱育児をやってきたわけですが、育児はなかなか大変です。 どれくらい大変におもったかというと、「まだ会社で仕事している方が楽だよな」と思えるくらいには育児は大変だと思いました。 毎晩のように夜泣きして起こされたり、原因もわからず泣き出して抱っこしても泣き止まなかったり、お腹が減っているはずなのにミルクを飲まなかったりと、 当たり前ですが子供は僕らの思うようにいくものではなく、そういうものと四六時中対峙している妻は本当にすごいなと思います。

そういった大変さと対峙してきたので、もうすぐ子供が生まれて1年経つので少しまとめてみようかなと思います。

前提

  • チームメンバー(同居人)は僕と妻、子供の三人
  • 僕は育休は取らず、妻はひとまず来年 4 月までは育休中
    • なので妻は四六時中子供と一緒
    • 僕は平日日中は仕事、帰ってから育児という流れ

属人性について

課題

まず一番最初に考えたのは育児業務の属人性についてです。 例を挙げると、

  • 授乳、およびミルク作り
  • 離乳食作り
  • おもつ交換
  • 泣いた時にあやす
  • 寝かしつけ
  • 夜泣き対応

などなど、細かく上げればきりがないくらいやることがたくさんあります。

で、僕は育休を取らないことにして、妻が育休でつきっきりで子供を見てくれている以上、どうしてもいろんな育児業務が属人化してしまいます。 属人化すると、妻がいないと回せない状況ができてしまい、妻も休まる日間もなく夫婦関係が悪化してしまいかねません。

また、これらの育児業務はタイトルだけ見ると単純作業に思えますが、細かく見ていくと結構気をつけることがあります。

例えばミルク作りの場合、

  • ミルクを作るタイミングはだいたい子供がお腹をすかせて泣いているときなので、すばやく作る必要がある
    • 極力お湯で作ったミルクを冷ます時間を短縮する必要がある
  • 我が家で使っている哺乳瓶はちょっと間違えると飲んでいる時にミルクがこぼれてくる
    • 子供にミルクがかかるし家具が汚れるので極力避けたい
  • 子供が飲みやすい適切な温度
    • これを間違えるとなかなか飲んでくれなかったりする
  • 次回のミルク作りのタイミングで利用する湯冷ましを予め作っておく
    • これがなくなると次回ミルクを作る時に時間がかかってしまう

などなど、いろいろ気をつけることがあります

対策

ペア作業

仰々しく書きましたが、要は妻と一緒にやってみるということです。 我が家の育児業務の第一人者の妻にナビゲータになってもらって一緒に作業をやってみることを心がけました。

こういった作業は妻本人もなれてきてしまうと、自然と気にかけていることや、無意識にやっている意味のある所作などがあるので、口頭で説明を受けてやるより、一緒にやりながら「それはなんでそういう所作が必要なの?」とか聞きながらやるのがその業務を習得するのに適しているように感じました。

また、子供が成長するにつれて、気をつけるポイントや手順が変わったりするので、そういったトレンドを押さえるためにも定期的にペア作業するようにしています。

大事なのは、極力夫である僕も関わろうとすることです。 どうしても日中いない身だとそういった 関わろうとする姿勢があるだけでも全然違ってきます。

作業分担の明確化

とはいえ、属人性が全て悪ではないと思っています。やっぱり作業の向き不向き得手不得手もあるし。 しかし、何が属人化しているか、どの作業が誰に属しているかと言うのは明確にしておかないと何かと衝突が起きます。 例えば、洗濯機を回すのは妻の中では暗黙的に僕がやることになっていたのですが、僕は妻が体調がよくなさそう、余裕がなさそうなときだけやるつもりだったりして、なんでやってなかったの!みたいな話になったりするわけです。

なので、当番表のようなものを作りました。

当番表は日常的に発生する家事育児の業務を洗い出して、それに対して主担当を割り振っていきます。 そこには諸々の状況を考慮していて、例えば僕が日中仕事をしていることや妻が洗剤での手荒れがひどいことなどを考慮して割り振りを行います。

これによって誰が何をやるのかの合意形成を取れるので衝突もなくなるし、その上で体調が悪いときなどにお互いに家事を依頼する流れになって家事がされなくて困ったみたいなことも防ぐことができました。

家事をする時間の捻出

課題

育児をし始めて強く感じたのは、今まで当たり前のように取れていた家事の時間が、子供の世話をしている事によってなかなか取りづらいということです。 うちの子供は親がそばにいないと寂しがって泣くことがあって(これも可愛いのですが)そうするとなかなか子供のそばを離れるタイミングが難しいのです。

また、大人だけで暮らしている場合よりも家事に時間がかかるということもあります。 例えば、洗濯は大人だけであれば最悪 2,3 日に一回回せば良かったりするかもしれませんが、子供がいる場合はすぐにいろんなものを汚したりするので、少なくとも 1 日に 1 回くらいは選択しなければなりません。

対策

自動化

一番効き目があったように思うのは家事の自動化です。要はお金で解決ですね。

いい時代に生まれたもので、今は家具にある程度のお金を変えれば家事を結構楽にしてくれます。 我が家が導入したのは以下のものになります。

  • 全自動洗濯機
    • 洗濯物を干す時間が省略できます。これが一番助かった。
    • 物によってはシワが目立つのでそういったものだけは自然乾燥しています。
    • 高額ですが、ちょうど前の洗濯機が壊れてしまったというのもあって踏ん切りがついたというのもある。

  • ホットクック
    • 材料を切って投入すれば時間が経てばできあがる家電
    • これがないと火をかけている時に台所から離れられないので、重宝しています。

  • 食洗機
    • 子供が生まれて引っ越したのですが、そこでたまたま最初から食洗機がついていた。
    • 食洗機にぶっこむだけ。洗う時間がだいぶ短縮できました。
    • あと、妻は手荒れとかもひどかったので、そういう改善も見られました。

実は妻は出産後2ヶ月で腱鞘炎になってしまい、重いものを持ったりするのがだいぶ辛くなってしまいました。(産後の女性には多いらしい。) そういった状況も家事の自動化によってなんとかやりくりできた感じがします。

苦労や喜びの共有

課題

育児をしていると、やっぱり嬉しいことや大変なことなど、いっぱいあるんですよね。 初めて寝返りをうったとか、初めてハイハイしたとか、良いこともあれば、今日は全然離乳食を食べてくれなかったとか、昨晩は深夜まで寝てくれなかったとか。

僕が日中いない中で特に妻はそういった喜ばしいことや苦しかったことをいっぱい体験しているわけです。

で、それを共有しないでいると、どうしても育児に対する当事者意識が薄れてしまいます。

なので、そういったことも極力共有する事になりました。

対策

写真での共有

ぼくらは mixi 社が運営しているみてねというサービスを使っています。 https://mitene.us/

このサービスは子供の写真共有に特化したサービスで、写真に対してコメントも付けられたり、家族というロールで親族なども招待することができる Private SNS になっていること。 何よりすごいのは容量無制限の無料のサービスであることです。無料に敵うものはない。

妻はほぼ毎日子供の写真を撮ってコメントで何があったかを共有してくれていて、僕としてはその日あったことをこれである程度把握することができています。

育児絵日記

妻は絵を書くのが好きで、育児絵日記をつけてくれています。 例えばこんな感じ。

f:id:yohei1229:20181031235959j:plain

これがまた良くて、写真と違った味わいと写真では表しにくいその日のハイライトを垣間見ることができます。

会話する時間をとる

これはルールとして決めていると言うよりは、僕が意識していることですが、毎日子供が寝たあとに極力妻と二人で会話をする時間を設けるようにしています。 話すことは他愛もないことで、

  • 今日何があった
    • おもしろかったこと
    • 大変だったこと
  • その他連絡事項
    • 予防接種次はいつになった
    • 保育園の応募の進捗状況
    • などなど

どうしても日中一人で育児をしている妻にとっては一人で抱えること自体が辛くなると思うので、極力会話量を減らさないようにしています。

まとめ

チームでなにかに当たるということは仕事も育児も同じ

まー無理やりアジャイルのプラクティスに沿っていろいろ書きましたが、今回整理して挙げた話は抽象化してみると育児だけではなく仕事でも同じことが言えるのだなぁと思った次第です。 今回整理した内容で言うと

  • タスクの属人性について => 属人性の排除
  • タスクの明確化
  • タスクの効率化
  • 情報共有による文化醸成と課題発見

みたいなことが抽象化すると言えるのかなと。 これらは仕事でも同じ話がありますよね。

どんなときでも改善する意識が大事

仕事にしろ育児にしろ、なにかをしていく上で課題が出ないことなんてなくて、その課題にどう立ち向かうか、どうやって今の状況をより良い方向に改善していくのかというのが大事なのかなと。 また、課題は解決する方法を考えるよりどういう課題設定をするかが大事だみたいな話がありますが、そのために如何に情報収集するか、如何にメンバーでコミュニケーションをとるかが大事なのかなと。

最後に

育児、家庭から学んだことを仕事に生かして、仕事で学んだことを育児、家庭に活かすフィードバックループがより活性化されると人生楽しそうだなと思いました。

Github の API を使って GraphQL を触ってみる

先日社内の勉強会で Github API を使って GraphQL を触ってみたので、ちょっとまとめてみようと思います。

参考にしたリンク

GraphQL のチュートリアルを見ながら、各文法を Github GraphQL API の Explore を使って実際にクエリを組んでレスポンスを見ていきます。

手始めに

まずは簡単なクエリから

query {
  viewer {
    name
  }
}

こういうクエリを投げてみると

{
  "data": {
    "viewer": {
      "name": "Yohei Honda"
    }
  }
}

こんな感じのレスポンスが返ってきます。 リクエストのクエリと同じような感じで返ってきてわかりやすい。

複数の field を取得してみる

query {
  viewer {
    name
    bio
    location
  }
}

レスポンスは以下の通り。

{
  "data": {
    "viewer": {
      "name": "Yohei Honda",
      "bio": "Ruby developer",
      "location": "Japan, Tokyo"
    }
  }
}

Alias

次に Alias を設定してみます。 例えば、使うときに Viewer だとちょっとわかりにくいかもしれないので myself っていう Alias を貼ってみます。

query {
  myself: viewer {
    name
    bio
    location
  }
}

レスポンスは以下。

  "data": {
    "myself": {
      "name": "Yohei Honda",
      "bio": "Ruby developer",
      "location": "Japan, Tokyo"
    }
  }
}

join みたいな感じ

次に、SQL の join みたいなことをしてみます。 ここでは Viewer(User) のリポジトリの最初の一件の name と description を取ってきます。

クエリ

query {
  viewer {
    repositories(first: 1) {
      edges {
        node {
          name
          description
        }
      }
    }
  }
}

レスポンス

{
  "data": {
    "viewer": {
      "repositories": {
        "edges": [
          {
            "node": {
              "name": "design-pattern-study",
              "description": "デザパタの勉強用リポジトリ"
            }
          }
        ]
      }
    }
  }
}

Fragment

次にフラグメント機能です。 フラグメント機能はクエリの一部を関数みたいに切り出すことが出来る機能です。

クエリ

query {
  viewer {
    ...userBasicFragments
  }
}

fragment userBasicFragments on User {
  name
  bio
  location
}

レスポンス

{
  "data": {
    "viewer": {
      "name": "Yohei Honda",
      "bio": "Ruby developer",
      "location": "Japan, Tokyo"
    }
  }
}

変数

GraphQL では変数も使えます。

クエリ

query Sample($repo_count: Int!) {
  viewer {
    repositories(first: $repo_count) {
      edges {
        node {
          name
          description
        }
      }
    }
  }
}

で変数は以下

{
  "repo_count": 1
}

レスポンス

{
  "data": {
    "viewer": {
      "repositories": {
        "edges": [
          {
            "node": {
              "name": "design-pattern-study",
              "description": "デザパタの勉強用リポジトリ"
            }
          }
        ]
      }
    }
  }
}

Directives

GraphQL ではクエリ内で if とかも使えちゃいます。

クエリ

query Sample($get_repositories: Boolean!) {
  viewer {
    name
    repositories(first: 1) @include(if: $get_repositories) {
      edges {
        node {
          name
          description
        }
      }
    }
  }
}

で引数

{
  "get_repositories": false
}

レスポンス

{
  "data": {
    "viewer": {
      "name": "Yohei Honda"
    }
  }
}

クエリ上 repositories を取ってきていますが、 get_repositories という引数が false なので 取ってこないようになっています。

感想

色々機能もあるし、API を使う側としては柔軟にいろいろできそうでいい感じですね。触ってて楽しい。 一方で API を用意する側は GraphQL のパーサーを用意したりしなきゃいけないので、結構大変なのかな。 そこら辺もライブラリやフレームワークが揃ってくればいいのかもしれませんが、用意する側の敷居はやはり高い気もしました。

CodeClimate をチームで導入してみた

この記事は Sansan Advent Calendar 2015 の 16 日目です。

CodeClimate をチームで導入してみたのでその経緯や良かった点などを書きたいと思います。

もともとの課題

ある日の会話

よくチームの KPT とかで、こんな会話がありました。

A 「最近コード汚くなってきましたねー」

B 「うーん、そうだね、言われてみれば確かに」

C 「・・・そう?」

コードの汚さは人によって価値観が違う

チームとして「コードは綺麗であるべき」という価値観はみんな持てているとは思います。 一方で、サービスのために一旦ある程度汚くても動くものをスピードを持って作らなければならないことはよくある話です。 (もちろん綺麗なコードをスピードを持って作れるようにしていく努力は惜しまないことを前提に。)

問題は、今どれくらい汚くなっていて、チームとしてどれくらい課題なのか、という共通認識を持つのがなかなか難しいということでした。

そこで CodeClimate

きっかけは、僕らのチームが Slack (有償)を導入し始めて、僕が個人的な興味で「もっと Slack の Integration 活用したいなぁ」と思って Integration の一覧を見て面白いサービスないかなぁと見ていて CodeClimate を見つけたことでした。

前述のような課題もあり、ちょっと高いけど入れてみようか、ということが部内で合意取れたので使ってみました。

CodeClimate とは

https://codeclimate.com/

簡単に言うと、

  • コードをファイル単位、リポジトリ単位でスコアリングしてくれる
  • コードの汚そうなところを Issue として管理してくれる

というものです。

対応している言語はざっと Document を見る限り

なんかが対応しているみたいです。

僕らのチームは Ruby で開発しているので、これ以降は Ruby における話をします。

お値段

まず、Public リポジトリは、他のサービスとかと同じように無料で利用できます。 Private リポジトリは、僕らが導入した頃はリポジトリ数でプランが分かれていて、利用していたのは 10 リポジトリまで $ 199 というプランでしたが、 最近変わったようで、今はユーザー数で課金がされるようになったようです。

https://codeclimate.com/pricing

CodeClimate の始め方

すごく簡単です。

  • CodeClimate に Sign Up する(Github アカウントでログインできます)
  • 解析したいリポジトリを選択する

これだけです。

どんなかんじか

CodeClimate の管理画面

f:id:yohei1229:20151223093013p:plain

こんな感じです。 リポジトリ全体のスコアは週次でメールでもお知らせしてくれます。

Github Pull Request Integration

CodeClimate には Github Pull Request Integration も用意されていて、 利用するとこんな感じに PR 上で新しい Issue の状況を教えてくれます。 f:id:yohei1229:20151223093636p:plain

Slack Integration

Slack Integration を利用すると、default ブランチにマージされる度に、スコアの変更を教えてくれます。

あと、CodeClimate はこの情報も含めて Feed も提供してくれていて、僕らのチームでは Slack の RSS Integration を利用して この Feed を Slack に流すようにしています。 f:id:yohei1229:20151223093511p:plain

使ってみた感想

CodeClimate のスコアをキーに、綺麗になった、汚くなったみたいな話がチームでされるようになった

こんな感じに、スコアを上げるモチベーションにもなりつつあります。

f:id:yohei1229:20151223093119p:plain

急いで作らないといけなくて汚く書いてしまっているのがわかって、逆に罪悪感が。。。

みたいな意見もありました。 やっぱりコードを綺麗にするうえで、元々の設計の良くない部分とかで、致し方なく汚くなってしまうケースなどもあって、 課題感が明確になって良くもありますが、そこをどうチームで捉えていくかというところはまだまだこれから考えていかなきゃいけないです。

やっぱり、機械にやらせられることは機械にやらせるべき

これは CodeClimate だけの話ではないですが、昨今システム開発に関する良いサービスがいろいろ出てきている中で、 適材適所で導入して、チームの課題解決や開発の効率化していくことは良いことだなぁと思いました。

余談

今回の記事で、過去の CodeClimate のスクショ撮ってて気づきましたけど、スコア悪くなってるスクショが多かったなぁ。。。

Electron で Remotty のクライントアプリ作ってみた

僕らのチームではこの前の神山.rb(https://kamiyamarb.doorkeeper.jp/) をきっかけに知った Remotty を使ってみています。 リモートワーカーがいるチームとしてはすごく良いツールです。

ただ、Slack のように常時立ちあげて利用するほど重宝しているツールであるため、 僕個人の使い方的に、ブラウザの 1 タブとして立ち上げるのではなく、クライアントアプリみたいな感じに利用したいと思いました。

そこで、最近興味を持っていた Electron で簡単なクライアントアプリを作ってみました。 作ってみたアプリは https://github.com/yonda/electron-remotty で公開しています。

前提

node は npm は入っていること。

導入

以下のコマンドで Electron をインストールします。

$ npm -g install electron-prebuilt

で、プロジェクト用のディレクトリをきって、npm init

$ mkdir electron-remotty
$ cd electron-remotty
$ npm init -y

package.json の main は main.js としておきます。

main.js の実装

まずは https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md 通りに main.js を作っていきます。

'use strict';

var app = require('app');
var BrowserWindow = require('browser-window');

require('crash-reporter').start();

var mainWindow = null;

app.on('window-all-closed', function () {
  if (process.platform != 'darwin') {
    app.quit();
  }
});

app.on('ready', function () {
  mainWindow = new BrowserWindow({width: 1280, height: 800});

  mainWindow.loadUrl('file://' + __dirname + '/index.html');
  mainWindow.on('closed', function () {
    mainWindow = null;
  });
});

僕は MacBookPro の 13 inch をつかっていて、ウィンドウサイズはフルサイズで起動したかったので width と height だけ少し変えています。

index.html の実装

ここは Quick Start とは少し変えていて、webview で remotty を表示するようにしています。 また、style タグで webview のサイズをウィンドウサイズに合わせるようにしています。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>remotty</title>
  </head>
  <body>
    <script>console.log("Hello World");</script>
    <webview id="mainWebview" 
      src="https://www.remotty.net" autosize="on"></webview>
    <style>
       webview {
         position: absolute;
         top: 0;
         right: 0;
         bottom: 0;
         left: 0;
       }
     </style>
  </body>
</html>

<script>console.log("Hello World");</script> という変な記述がありますが、これは後ほど説明します。

起動

あとは起動するだけで、一通り完成です。

$ electron .

すごく簡単。デスクトップ通知もこれだけで出てくれます。

ハマった点

ここはちょっと良くわかっていないのですが、何故か webview を追加しただけだと何も表示されませんでした。 調べてみると、何かしら script タグがないと動いてくれないらしい。 ので、何かしら script が必要になるまでは <script>console.log("Hello World");</script> みたいに適当な script を突っ込んでおきました。

参考

http://qiita.com/yoching/items/b1eba88f75320a61bcc6 https://github.com/atom/electron/issues/1117

いろいろ便利にしたこと

コピペやリロードができるようにした

このままではコピペやリロードは出来ないので、https://github.com/atom/electron/blob/master/docs/api/menu.md を参考に、コンテキストメニューを追加しました。 (追加した、というより会社の後輩に PR もらった。感謝。)

main.js

app.on('ready', function () {
  // 省略
  setApplicationMenu();
}

function setApplicationMenu (){
  var Menu = require('menu');
  var menu = Menu.buildFromTemplate([
    {
      label: "Application",
      submenu: [
        {label: "About Application", selector: "orderFrontStandardAboutPanel:"},
        {type: "separator"},
        {label: "Quit", accelerator: "Command+Q", click: function() { app.quit(); }}
      ]
    },
    {
      label: "View",
      submenu: [
        {
          label: 'Reload',
          accelerator: 'CmdOrCtrl+R',
          click: function(item, focusedWindow) {
            if (focusedWindow)
              focusedWindow.reload();
          }
        },
      ]
    },
    {
      label: "Edit",
      submenu: [
        { label: "Undo", accelerator: "Command+Z", selector: "undo:" },
        { label: "Redo", accelerator: "Shift+Command+Z", selector: "redo:" },
        { type: "separator" },
        { label: "Cut", accelerator: "Command+X", selector: "cut:" },
        { label: "Copy", accelerator: "Command+C", selector: "copy:" },
        { label: "Paste", accelerator: "Command+V", selector: "paste:" }
      ]
    }
  ]);
  Menu.setApplicationMenu(menu);
}

これでコピペやリロードができるようになりました。

リンクをクリックしたらデフォルトブラウザで開くようにした

このままでは外部リンクが開けなかったので、https://github.com/atom/electron/blob/master/docs/api/web-view-tag.md を見つつ対応してみました。

index.html

<script>
onload = function() {
  var webview = document.getElementById("mainWebview");

  webview.addEventListener('new-window', function(e) {
    require('shell').openExternal(e.url);
  });
}
</script>

使ってみての感想

Electron すごく便利。今回みたいな WebView 貼るだけだったらほんと 30 分あればできるし、ここからクライアントアプリっぽくいろいろカスタマイズも出来そう。いろいろ試してみたい。

神山.rb に参加してきました

神山.rb

徳島県神山町で開催された勉強会に縁あって参加してきました。

kamiyamarb.doorkeeper.jp

話したこと

rails-api について

www.slideshare.net

リモートワークについて

訳あって非公開

所感

リモートワークをテーマにしたセッションもあることから、今回はリモート参加も OK ということで、skype + remotty でリモート参加者とつなげながら勉強会を実施しました。 僕はどちらかというと主催者側にいたのですが、リモート周りのセッティングでトラブルが続き(会場の wifi が使えない、skype で大規模障害が発生する etc...)結構大変でしたが、結果的にリモートの大変さを実感して頂けたり、remotty や appear.in などのリモートツールを参加者の方に使って頂くいい機会になったり、最後はリモート参加者も含めての集合写真を撮って一体感を感じられたり、非常にいい経験ができました。次回あればまた参加したい。

remotty www.remotty.net

あと、二次会の Café on y va さんは本当にご飯が美味しかったです。

Café on y va(カフェ オニヴァ)

virtus-dirty_attribute について

最近、仕事上の Ruby プロジェクトで、"モデルに変更があった時だけそのモデルに対して update したい" みたいな要望があって、いろいろ調べたのですが、最終的に virtus-dirty_attribute というのを使うことになった。

virtus-dirty_attribute の使い方

https://github.com/ahawkins/virtus-dirty_attribute

README にも書いてあるけど、

class Hoge
  include Virtus.model
  include Virtus::DirtyAttribute

的な感じに include すると、hoge.dirty? とか hoge.clean? とかで変更があったかどうかが見れるという代物。

へー、便利だなー、でも Rails さんそこらへんやってくれないのかしら?と思っていたら、やっぱり一応あった。それが ActiveModel::Dirty。

ActiveModel::Dirty

http://api.rubyonrails.org/classes/ActiveModel/Dirty.html

なにやら define_attribute_methods とか定義したり、各 attribute のメソッドを定義して hogehoge_will_change とか呼んであげたりと、結構色々やってあげなきゃいけなそう。。。

ActiveRecord 使っているとそこら辺勝手にやってくれるらしく、ActiveRecord のモデルでやる文には便利そう。

というわけで

今回 "モデルに変更があった時だけそのモデルに対して update したい" ということがしたかったのは、たまたま ActiveRecord のモデルじゃなかったので、virtus-dirty_attribute で行くのが良さそう。

rbenv 環境下で Atom(Github) で Rspec を動かしてみた

ちょっと前に Atom のβ版の招待申請を出していて、 「Welcome to Atom」というメールが届いて、使ってみたらなかなかいい感じ。

atomRspec のPackage があったので、ちょっと欲が出て install して atomRspec 実行できるようにしたところ、

$ command not found 'rspec'

的なエラーが出て Rspec が実行できなかった。

むーなんで?と思って調べていたところ、 https://github.com/fcoury/atom-rspec/issues/10 の Issue があって、読んでみたら、

Atom uses bash. so, you have to setup .bash_profile/.bashrc as https://github.com/sstephenson/rbenv

と書いてあるではありませんか!

たしかに、この Issue の人同様、私は zsh ユーザーだったので、 .bashrc に rbenv の記述をしたところ、Rspec 実行できた! 勝手にペインを分割してテスト結果も出してくれていい感じ。

sublime text でもできていたことだけど、エディタ内でテストが実行できるとか、 ちょっと感動しますね。