Sansan株式会社を退職しました

退職エントリーです。

 

2012年1月からお世話になっていたSansan株式会社を2024年3月15日(最終出社は2月29日)で退職します。

 

Sansanでは主に名刺データ化システムの開発を7年ほど、その後は名刺管理サービスEightの開発に5年ほど携わりました。

エンジニアとして転職してくるまでウェブアプリケーションの開発経験がない中で.NET C# から始まり Ruby on Rails のサービスの1→10のフェーズに携わらせてもらいました。1プレイヤーとして開発したり、チームリーダーとしてチームをリードしたり、マネジメントにも挑戦させてもらいました。

会社の規模も入った頃は50名もいないところから今では1000名超える社員数になり、非常に貴重な経験をさせてもらった会社や関わってくださった方々には感謝しかありません。

 

思い返すと、大変だったことばかりでしたが楽しかった記憶しかありません。大変と楽しいは両立するんですね。入ったばかりは全く役に立ってなかったですが、何とかこの会社に、この事業に自分なりに貢献しようと必死でしたし、でも得られるものや刺激もいっぱいあって。少しずつ自信のようなものがついてくるとまた別のチャレンジをすることになったり、本当に休まることなく楽しく向き合い続けられた12年間だったと思います。それを続けてこれたのも一緒に働く方々がすごく魅力的でそれに引っ張られてここまでやってこれたなーと思っています。

 

学べたことや得たものはいっぱいあり過ぎてあげたらキリがありませんが、エンジニアとしてはほんと貢献できる力が0のところから、当たり前に開発していくための知識、スキルを学ばせてもらいましたし、その中で自分なりに大事にすべき価値観や考え方を身につけることができました。これも優秀かついいサービスを世の中に提供したいという強い想いをもって仕事に向き合っている方々に囲まれて仕事をしてこれたことが強く影響していると思ってます。

また、数十人しか社員がいない中で自分がやるべきことを自分で定める、役割にとらわれずに何でもやる、みたいな自分の強みはあのフェーズのこの会社に入れたからこそ得られたものだなぁと感じています。

あとは、そんな中で関わってきた方々と仕事だけではなくプライベートでも親しくさせてもらえてるのも自分にとっては非常に大きな財産です。退職した後も是非仲良くしていただけると幸いです。

 

次は決まっていて3月下旬から新しいところでの仕事が始まりますが、そっちの話はまた落ち着いた頃に気が向いたらしたためようかなと思っています。とりあえずは来週一杯までゆっくり休んで、その後は気を張り過ぎず自分なりに頑張ってみようと思ってます。

 

リングフィットアドベンチャーと私

また久々の投稿です。毎年 Advent Calendar のときにしかブログ書いていない気がする。 本記事は https://adventar.org/calendars/3924 の 22 日目の記事です。

AdventCalendarを見るとちゃんとした技術ネタばかりで若干気が引けますが、軍用レーションの記事をみてまぁこれくらいなら許されるだろうと思っています。

qiita.com

概要

10月末からリングフィットアドベンチャーをやり始めて、いい感じなのでそれを自分なりにまとめようと思います。

www.nintendo.co.jp

何故買ったか

もともと僕は大学時代までは身長170cmに対して体重50kgもないガリガリ体型だったのですが、社会人になって食生活(主にお酒)によってブクブク太っていき、ガリガリ体型は見る影もなくお腹ポッコリ体型になってました。

ちゃんと運動しなきゃなーと思って、色々(会社のサッカー部に顔を出したり、ランニングに精を出したりetc)やってみたのですが、どれも長続きせず、お腹ポッコリ体型が改善されることはありませんでした。 実は筋トレも今年の頭くらいに習慣化しようと頑張った事があったのですが、これも全然続けられませんでした。

一方で、子供ができてそのうち子供の運動会行ったり、子供と海に行ったり、色々子供と運動する機会も出てくるのかなと思う中で、このお腹ポッコリはどうにかしないといけないなという思いはありました。

そんな中、リングフィットアドベンチャーが発売されて、ネットや社内の購入した人から「リングフィットアドベンチャーいいぞ~」と言われたのがきっかけでした。

運動に対する自分の課題感

前述の通り、社会人になってからこれまで色々運動を習慣化しようと色々頑張ったのですが、全く定着しませんでした。 自分なりに習慣化出来なかったのは以下のような理由があるかなと思います。

頑張ってるけど、ちゃんと鍛えられているか不安になる

ランニングや筋トレなど頑張って見ていましたが、専門家についてもらっているわけでもなく、独学でやってみているにすぎず、「きついけど、これはちゃんと自分の体のためになっているのか?」という不安が沸き起こり、その不安に対して、(当然ですが)すぐには体型が変わるわけではないので更に不安になり、最終的に結果が出る前にやめてしまう、というサイクルを続けていました。

そもそも単純な運動って何が楽しいの?

選んだ運動が良くなかったのかもしれませんが、ランニングや筋トレは、ほぼ単純動作の繰り返しで、「いつか体型が変わるぞ!」みたいな結果に対するモチベーション以外を持つことが出来ませんでした。単純動作の繰り返しは我慢でしかなく、ただ辛いことを我慢して頑張るという感じで、楽しくなかったので習慣化出来なかった側面は大きかったと思います。

(外に行かなきゃ出来ない運動について)いろんな言い訳がしやすかった

特にランニングについてなのですが、ランニングは外を走ることになります。外を走るにおいて、いろんな環境要因で外に出られない(ことを言い訳にしやすかった)こともランニングを継続できなかった理由かなと思います。 例えば、春は花粉症で外を走るのが辛く、夏はあつすぎて走るのが辛く、冬は寒すぎて走るのが辛く、雨の日は風邪ひきそうなので走らず、、、といった感じです。実質走る言い訳をしなくて済むのは秋の晴れた日だけで、そりゃ習慣化できるはずがなかった。

総じて

ここまで読んでいただき分かる通り、総じて僕は運動に対する意思が弱いというか、そもそもそんなにモチベーションが持てなかったのだということだと思います。でも痩せたいし、いい体型になりたい、どうしよう。そんな感じ。

ではリングフィットアドベンチャーはどうなのか

2019/10/26 に購入して、この記事の投稿日(2019/12/22)で58日中、36日リングフィットアドベンチャーをやっていました。 2日に1日以上、週で考えるとおよそ週4日くらいは出来ている感じです。 それをもう 2 ヶ月くらい続けられていると考えると、今までの自分としてはちょっと驚きです。

何故続けられているか

ゲームなので少なからずモチベートしてくれる

僕はいつもやるとき、アドベンチャーモードという、筋トレアクションRPGモードでやっているのですが、これがいい塩梅で、1ステージがいい感覚で区切られていて、僕の場合だとちょうど2-3ステージやるとちょうどヘトヘトになるくらいになっていて、筋トレの1セットをゲーム感覚でクリアしていく感じで、本当にゲームやっている感じと筋トレやっている感じの両方が持てる様になっています。 別にストーリーは面白いわけではないのですが、アクションゲームとしてちゃんとゲームになっていて、そのゲームのインターフェースが筋トレになっているような感じです。

少なくとも個人的には「筋トレ単純作業でつまらん」からは開放されて楽しみながら筋トレできています。

ゲームが運動についてちゃんとアドバイスしてくれる

筋トレ中の姿勢は、足に付けたコントローラーとリングコンが適切な姿勢になっているかを見てくれるので、安心感があります。 運動のペースについても、必要に応じて「今日はそろそろやめますか?」と聞いてくれたり、設定している運動負荷が低くて運動時間が長いと運動負荷を上げることを勧めてくれたりと、ちゃんと目的と状況に合わせて設定変更を促してくれるのも良いです。

運動後のストレッチも、その日重点的に使った部位をストレッチ出来ていて、ある程度パーソナライズしてくれるのも良かったです。

室内かつどこでもできる

Nintendo Swith を持ち運べてある程度運動するスペースが有るところだったらどこでもできるというのが僕にとっては大きかったです。

僕は平日は子供が寝静まった後の 20:00 くらいから大人の寝室でこのゲームをやるのですが、Nintendo Switch さえあればテレビがなくてもできるのが良いです。 当然外に行く必要もなく、雨や気温などを言い訳にすることもないのも良かったです。

社内にやっている人がいる

弊社社内のSlackに #ring-fit-adventure チャネルがあって、そこで今日やった内容や、頑張ったことなどを共有しあって切磋琢磨しています。 周りにやっている人がいると、「みんなもやってるし、今日も頑張るか」となったり、「あの人もうLv.XXまでいったのか、僕も頑張ろう」となったりして、とてもモチベーションになっています。

社内Slackの#ring-fit-adventureチャネルの皆さん、いつもありがとうございます。

f:id:yohei1229:20191222161848p:plain
こんな感じにみんな頑張ったのを報告しあってます

リングフィットアドベンチャーをやり続けてよかったこと

見た目お腹のポッコリが改善されてきた

残念ながら体重計を導入せずに始めてしまい、数値では測ることが出来ていないので完全に体感値になってしまいますが、ぽっこりしていたお腹がだいぶ改善されました。 多分筋トレだけじゃなくて、朝晩にプロテイン導入したり、多少食生活も改善(ただし、暴飲暴食を控えた程度)したりもしているので、そこらへんも効いてきているのだとは思いますが、間違いなく運動の効果も出ているのではないかと思います。

体の調子が良い

今まで腰痛や肩こりが酷くて、少なくとも月イチで整体に通っていたのですが、肩こりや腰痛が改善され、前回整体に行った際に、整体師の方に「今までで一番体の状態が良い」といってもらえました。 肩こりや腰痛が全くなくなったわけではないのですが、多分筋トレによって姿勢が良くなったのと、いつも動かさない筋肉を動かすようになってこりにくくなったのではないかと思います。

まとめ

僕みたいなグータラでも楽しく運動できるので、ゲーム感覚で筋トレしたい人はおすすめです!

年内最終出社日には社内でリングフィットアドベンチャーオフ会を開催する予定で、みんなでビクトリーしてこようと思います。

子供が生まれてもうすぐ 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(カフェ オニヴァ)