読者です 読者をやめる 読者になる 読者になる

スプーキーズのちょっとTech。

SPOOKIES社内のより技工的な、専門的なブログページです。

GHCJSを使う

Haskellロゴ

先日、この記事を読む機会があり、GHCJSを使ってみたくなったので、セットアップ〜DOMを生成してaddEventListenerぐらいまでの流れを書きます。

GHCJSとは

GHCJSは、Haskellを書くとJavaScriptを吐いてくれるコンパイラです。

GHCJSのセットアップ

前提

  • OSが*nix
  • 以下のツールがインストールされていること
  • StackとHaskellを普通に使ったことがあること
    • これらの説明はしません

GHCJSのビルド

GHCJSをビルドするためのディレクトリを作成し、stack.yamlを作成します。

$ mkdir ghcjs-build
$ cd ghcjs-build
$ vim stack.yaml

stack.yaml

flags: {}
extra-package-dbs: []
packages:
- '.'
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0_ghc-7.10.3:
        url: https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz
extra-deps: []
compiler-check: match-exact
compiler: ghcjs-0.2.0_ghc-7.10.3
resolver: ghcjs-0.2.0_ghc-7.10.3

そして、GHCJSをビルドします。

$ stack build

結構時間がかかります。だいたい30分ぐらいです。

GHCJSにパスを通します。

$ export PATH=PATH:$HOME/.stack/programs/x86_64-osx/ghcjs-0.2.0_ghc-7.10.3/bin/

GHCJSで何か書く

GHCJSのセットアップ

まず、適当にプロジェクトを立ち上げます*1

$ stack new ghcjs-test

生成されたstack.yamlの、resolverとcompilerを、以下のように置換します。

compiler: ghcjs-0.2.0_ghc-7.10.3
resolver: ghcjs-0.2.0_ghc-7.10.3

このままstack buildしようとすると、stack setupを先に実行しろ、と怒られるので、言うとおりにします。

$ stack setup

非常に長い時間がかかります。だいたい1時間ぐらい掛かります。

これが終わると、HaskellをJavaScriptにコンパイルすることができるようになります。

$ stack build

生成されたJavaScriptファイルは、プロジェクトディレクトリ直下の、

.stack-work/install/x86_64-osx/ghcjs-0.2.0_ghc-7.10.3/ghcjs-0.2.0.20151230.3_ghc-7.10.2/bin/ghcjs-blog-exe.jsexe/

にあります。 ghcjs-blog-exe.jsexe以下には幾つか.jsファイルがありますが、all.jsに全てのコードが入っているようです。

これをhtmlファイル内で読み込めば、Haskellのプログラムをブラウザ上で動かすことができます。

DOM操作ライブラリ"ghcjs-dom"の導入

Haskellの標準ライブラリではDOMを操作することはできないので、GHCJS用のDOM操作ライブラリであるghcjs-domを導入します。

プロジェクトのcabalファイルに、以下のように追記します。

...省略...

library
  hs-source-dirs:      src
  exposed-modules:     Lib
  build-depends:       base >= 4.7 && < 5
                     , ghcjs-dom              <== ココ
  default-language:    Haskell2010

...省略...

このままstack buildしようとすると、

While constructing the BuildPlan the following exceptions were encountered:

--  While attempting to add dependency,
    Could not find package ghcjs-dom in known packages

--  Failure when adding dependencies:    
      ghcjs-dom: needed (-any), stack configuration has no specified version (latest applicable is 0.2.3.1)
    needed for package ghcjs-test-0.1.0.0

Recommended action: try adding the following to your extra-deps in /home/sangenya/.apps/spoo-blog/stack.yaml
- ghcjs-dom-0.2.3.1

You may also want to try the 'stack solver' command

と言われます。

これを解決するには、上記エラーに書いてあるように、stack.yamlextra-depsという項にghcjs-dom-0.2.3.1を加えるか、stack solverコマンドを叩く必要があります。 後者は便利ですが、メモリをめちゃくちゃ喰います。私の環境では2~3GBぐらい持って行かれました。 前者はその心配をしなくても良いですが、dependency treeが深いライブラリを使うときは大変です。お好きな方をお選びください。

コードの書き方

後述の「突然の死ジェネレーター」のソースを見てもらえばわかりますが、基本的にはMonadIOモナドを駆使する感じです。

私がコードを書いた時は、

  • 書きたい処理をJavaScriptで考える
  • →ghcjs-domのライブラリから似たような名前の関数がないか調べる(getElementByIdなど)
  • →見つからなければghcjs-domのgithubレポジトリを検索する
  • →型から使い方を推測してコードを書く

の流れでだいたい行けました。

作ったもの

突然の死ジェネレータを作ってみました。

実際に書いたコードは以下のとおりです。

Haskellのコードは両方合わせて60行強程度に収めることが出来ました。

GHCJSを使ったことがない人でも、HaskellとJavaScriptを触ったことがある人なら、だいたい何をやっているのか解ると思います。

感想

生JavaScriptを書いてるみたいで正直つらい。

確かに、(Haskellのサブセットとか、Haskell-likeな言語ではない)本物のHaskellでブラウザで動くものを作れるのは楽しいし、生JavaScriptを書くよりは幾分簡潔に出来てる気はしますが、やってることは手続き型言語です。 もっと規模が大きなものを作るのなら違うのかもしれませんが、正直このくらいの規模のものを作るなら、生JavaScriptを書いたほうがいいのでは、と思います(Haskell好きなら楽しいけどな!)。

とはいえ、react-fluxghcjs-vdomなど、GHCJSで動くライブラリなども出てはいるので、将来的にもっと楽になる可能性はあると思います。 特にreact-fluxの方は、ドキュメントもちゃんと書いてあるっぽいし、試してみたいですね。

あと、生成されたJavaScriptファイルのサイズがめっちゃでかいです。60行強のHaskellコードが1MBぐらいのJavaScriptになります。

*1:Stackのghcjs用のテンプレートもあるのですが、2016-03-27現在はうまく動かないみたいです。動かし方知ってる人がいたら教えてください。

ナレッジは、esa.io でしょ

esa.io Gitlab Slack Backlog

人って難しいですよねー。だけど、一番おもしろいと感じる西塚です。

プログラムは、嘘つかない。

バグを憎んで、人を憎まず。

さて、

社内の情報を育てる

以前の記事でも書きましたが、うちは社内共有(ナレッジマネジメント)に esa.io を使っています!という話。

長く利用していると使う側のスキルも向上していくし、愛着が湧いてくる影響もあるかもしれませんが、 esa.io はかなり気に入ってます。

ちょうど1年前くらいから利用していて、無料体験からすぐに有料版で利用しています。

開発サービス変遷

Google Site → Backlog Wiki → GitLab Wiki → esa.io

Trac → Mantis → Redmine → Backlog

SVN → GitLab

MSN Messanger → Skype → Slack

Html → WordPress → GitHub Pages

思い出しながら書いているので、抜けがあたったりするかもしれませんが、だいたい上記のように移行してきています。 だいたいです。

サービスが変わる度に移行のエネルギーが必要なのですが、やはり新しいものは進化していて定着すると、移行して良かったと手放せなくなります。

esa.io も正に、それの1つです。 Backlog は気に入ったという話を以前書いたと思うのですが、それ以上に esa.io は私に刺さっています。

まず、コンセプト

f:id:spookies-nishizuka:20160226233515p:plain

最高ですね。完璧ですね。

MackerelのMeetupで、最近上場したはてなのCTOさんが掲げてた、「エンジニアをワクワクさせる」サービスも良いですが、しんぷるいずべすと。

かわいいデザインですが、使い勝手はかなり追求されていると感じます。

なので、記事を書くのが面倒にならない。

Google Site は WYSIWYG なので、簡単なはずですが、逆に細かいスタイルに惑わされて意外と面倒。

やはり開発のナレッジは、今は Markdown で記述する時代ですよね!? そうです。

Backlog / GitLab の Wiki 機能、Qiita Team も試しましたが、記事のカテゴライズ、リンクの強さが esa.io は際立ちました。

f:id:spookies-nishizuka:20160226234038p:plain

今後の esa.io にも期待!

esa.io を見つけた時は、開発メンバーが開発1名デザイナ1名の2名体制ということで、この体制で大丈夫か?という危惧もありましたが、問い合わせの返答の早いこと早いこと。

CSとしても素晴らしく、激感動しました。

そして、小規模の体制ではあまりない API が早々に実装されたのも、魅力の1つです。

以前、GitLab ⇔ Backlog を連携している記事を書きましたが、APIは社内の開発サービスを一体化できる重要な要素となります。 これは、また別に書きます。

はてなさんのサーバ管理サービス Mackerel でも感動しましたが、最近は開発の良いサービスがいっぱいありますねー。 うちも、そういうものを生み出さないといけないですねー。

ともあれ、 餌(esa) のおかげで、社内情報はひよっこエンジニアと共に、すくすくと健やかに育っております。

esaさんには、いつか Evernote までも凌駕して欲しいです。はい。

と、熱く esa.io 愛を語ってしまいましたが、今後の動きにも期待しております。

ノベルティ欲しいな~ チラッ と言ってみる。

おそまつ

GitLabとBacklogの連携

記事を書いて寝かしておいたら、忘れてしまって冬になってしまった西塚です。

最近、冷えますが、皆様いかがお過ごしでしょうか。

今回もスプーキーズで利用している開発サービスの話です。

GitLabとBacklogの連携

labs.spookies.co.jp

以前の記事でも紹介しましたが、スプーキーズではGitLabとBacklogを利用しています。

Backlogが提供しているGitリポジトリを利用していないので、そのメリットであるGitのCommitとタスクを関連付けるということが出来ません。

そこで、WebHookとAPIを利用してこれを独自実装しています。

GitLab ⇒ Backlog

GitLabのCommit情報やMergeRequest(PullRequest)から、対応するタスクを参照する機能は、GitLabの設定で実現することができます。

今まではその機能を知らずに、GitLabのViewをカスタマイズすることで実現してましたが、サーバ移行時に設定を見なおしていたら、この機能を発見しました。

GitLab設定

標準はJIRAまたはRedmine用の設定なのですが、Backlogも近い(URL)形式となっているので、設定を応用できます。

  ## External issues trackers
  issues_tracker:
    # redmine:
    #   title: "Redmine"
    #   ## If not nil, link 'Issues' on project page will be replaced with this
    #   ## Use placeholders:
    #   ##  :project_id        - GitLab project identifier
    #   ##  :issues_tracker_id - Project Name or Id in external issue tracker
    #   project_url: "http://redmine.sample/projects/:issues_tracker_id"
    redmine:
      title: "Backlog"
      project_url: "https://xxx.backlog.jp/projects/:issues_tracker_id"
      issues_url: "https://xxx.backlog.jp/view/:id"
      new_issue_url: "https://xxx.backlog.jp/add/:issues_tracker_id"

一時期、GitLabのソースを改変していた時期もあったのですが、マージやメンテが面倒だったりするので、設定だけの方式に切り替えてます。

上記設定により、GitLab の Issue タブを押した際、新規課題を押した際に、Backlogに遷移します。

また、コミットメッセージやプルリクエスト(GitLabではマージリクエスト)に、Backlogの課題IDをつけるように運用しています。

これにより、GitLabからそのBacklog課題へのリンクが自動的に生成されます。このコミットは、どのような課題を解決するために改修したのかがすぐに辿れるようになっています。

Backlog ⇒ GitLab

Backlogの課題からGitLabのCommit情報を参照する為に、Commitされた際にその内容をBacklogにコメントに追加することで実現しています。

GitLab にコミットメッセージもしくは、ブランチ名に課題IDを入れることで自動的に該当する課題にコメントが付加されます。

f:id:rhymester19:20151015171431p:plain

ちなみに、GitHub から Backlog はこんな感じ。

f:id:rhymester19:20151015171448p:plain

Ruby のプログラムで、GitLabのコミットをWebHookで拾って、Backlog API を利用して、該当課題にコメントつけています。

  def parse_json(json)
    event = JSON.parse(json, :object_class => HookBaseObject)
    event.extend(PushEvent)
    event.repository.extend(Repository)
    if event.commits
      event.commits.each { |commit| commit.extend(Commit) }
    end
    event
  end

  def git_push_to_backlog(event)
    description = event.repository.description
    return unless description

    # ex. [master]xxx@xxx.git.backlog.jp:/SANDBOX/sandbox.git
    matches = description.scan /(?:\[(\S+)\])?(\S+?@\S*git.backlog.jp:\S+\.git)/

    Dir.chdir(event.repository.local_path) do
      begin
        matches.each do |branch, url|
          if branch
            system('git', 'push', '-f', url, branch)
          else
            system('git', 'push', '-f', '--mirror', url)
          end
        end
      rescue => error
        log_error(error)
      end
    end
  end

  def build_comment(commit, event, signature)
    comment = ''
    branch_name = event.ref_name
    branch_url = event.repository.branch_page_url(branch_name)
    comment << "**Author:** #{commit.author.name}\n"
    comment << "**Branch:** [#{branch_name}](#{branch_url})\n"
    comment << "**Commit:** [#{commit.id[0,7]}](#{commit.url})\n"
    comment << "\n"
    comment << commit.message.gsub(/^/, '>') + "\n"
    comment << "\n"
    comment << signature
  end

@ つけることで、メンバーにお知らせしたり、 @+1h で時間をつけたり、 #fix で課題を完了させたり、 もしています。

ついでに、Slack にも連携してるので、誰が何の課題をしていて、どんなコミットしたのかは一目瞭然です。

いまは、HubotもBacklogに連携すべく、ゴニョゴニョしていますが、これはまた別の機会に。

それでは。もう少し寝てきます。

RaspberryPiと人感センサーで監視カメラを作ってみた

こんにちは。IoT開発部(仮)の西村です。
犬のしつけ教室に行ったら、先にあなたの子供をしつけてくださいと怒られました。他人任せはダメですね。とほほ。

先日、社内メンバーでランチに行った際に、IoT関連でなんかやってみたいよね。 という話になり、少し前からチラホラと名前を聞いてたRaspberryPiを使ってなんか作ってみようぜ! という事になりました。

何作んの?

さて何を作ろう?!という事で、
オフィスに誰か入ってきた時に、カメラで撮ってslackに流したら社内の動きがわかって便利だよね。
廊下に置いて、お客さま or 大家さんが来たらサッと扉を開けて、最高の笑顔で迎えてみようか?
なんて話になりました。

ということで、「誰かきたかもよ」君を作成しました。

ラズパイ本体と各種パーツ購入

amazonで以下の製品をポチりました。

だいたい次の日には届きました。便利ですね。
ちなみに、ラズパイをカートに入れたらamazonがレコメンドしてくれる [Transcend microSDHCカード 32GB]を買ったんですが、何度やり直してもOSのインストールがうまくいきませんでした。
東芝製のものを買い直したらあっさり成功したので、相性のようなものがあるのかもしれません。あまりお勧めを鵜呑みにするのはよくないですね。

手順1 SDカードにOSをダウンロード・インストール

まずSDカードを

SDカードフォーマッター

というツールを使ってフォーマットします。

次にraspberrypiサイトから、OSイメージをダウンロードしてきて、SDカードにコピーします。

raspberrypi本体にSDカードを刺して、キーボード・マウスを取り付け、電源としてのMicroUSBを挿したら起動し、インストールが始まります。
本体には電源ボタンとかないんですね。

手順2 各種パーツを取り付ける

OSのインストールが一通り終わったら、一旦電源を落として、センサー等各種パーツを取り付けます。

正直、どこに何をつけたらよいのか知識がなく困ったのですが、Qiitaのcigalecigalesさんの記事 を参考にして取り付けました。
人感センサー部分の設定に関しては、上記記事内でも紹介されてますこちらのサイト を参考にさせてもらいました。
カメラモジュールは本体に刺すだけです。

f:id:spookies-nishimura:20151209225356j:plain

手順3 無線LANの設定

参考サイトはたくさんあると思いますが、 lsusb コマンドで無線LANモジュール機器が確認できたら、

  • SSID, 暗号キーを設定
  • 固定IPの設定

を行い、ネットワーク再起動します。

手順4 プログラムを書く

今回のプログラムの流れとしては、以下のような感じです。

  • 1sec毎にループし、人感センサーの反応をチェック
  • センサーが反応したら1sec挟んで写真を2枚撮る
  • 2枚の画像の差分解析を行う
  • 一定以上の差分があれば、SCPで写真を画像公開用のサーバに送る
  • slackに、写真のURLとともに「誰かきたかもよ」とメッセージを送る

利用する各種moduleのimport

import os
import commands
import time
import RPi.GPIO as GPIO
import slackweb
import picamera
from paramiko import SSHClient, AutoAddPolicy
from datetime import datetime

画像の差分比較(ImageMagickを利用)

ImageMagickをインストール

sudo apt-get install libjpeg-dev imagemagick

os.system('composite -compose difference ' + filepath + ' ' + filepath_check + ' ' + filepath_diff)
diff_num = commands.getoutput("identify -format \"%[mean]\" " + filepath_diff)

画像が変化したと判断するための差分値は 1500 以上にしてますが、このあたりは環境等にもよると思います。

slackに通知

Qiitaのsatoshi03さんの記事を参考にWebHookURLを取得して、slackwebモジュールを利用して通知します。

slack.notify(text="誰か来たかもよ.")
slack.notify(text="WEBサーバに投稿した画像URL")

手順5 スクリプトをデーモン起動させる

常時起動するために supervisor をインストールします。

sudo apt-get install supervisor

human_sensor.conf を作成し、設定を行ったら

sudo supervisorctl start all

でデーモン起動させました。

設置

さて、この「誰かきたかもよ」君をオフィス内の扉の前に設置しました。
これで誰か来たとき、帰る時に、slackに通知されるようになりました。

f:id:spookies-nishimura:20151209225804p:plain

カメラの前にいろいろものを置きすぎて鬱陶しいですが、現状こんな感じ。

いたずら

同じものをもう1台作って東京オフィスにも設置してみました。
しばらくはうまく動いてたのですが、誰かがトイレに行く際に、マッハキックをかましたようで、「誰かきたかもよ」君が倒れ、延々と暗い画像を映し続けてました。

f:id:spookies-nishimura:20151209225826p:plain

そこで不意に、とてもとても怖い写真をslackに投稿してみました。
真夜中にです。

そしたら

f:id:spookies-nishimura:20151209225808p:plain

という反応を示してくれました。
ちょーびびってる。けけけ。

まとめ

SORACOM Airや、akerun などIoT製品が続々登場し、身近な物になってきました。 最近知った、MaBeee などは、見ててとてもワクワクします。
弊社でも、そんな製品・サービスづくりに積極的にチャレンジしたいと思います。

さてインフラは整ったので、お客さま・大家さんに最高の笑顔をご提供できるように 全メンバー手鏡を持ち、朝から夜中まで自主練をしております。

f:id:spookies-nishimura:20151209232127p:plain

うーん、もう少しですね。

それでは、私も自主練に戻りますので、失礼致します。

犬と停電とNetatmo

今年の春に犬を飼い始めました。 トイプードルという犬種なのですが、プードルは、大きさによって、以下のような名称で呼ぶらしいです。 (一部、愛称での区分もあるとのことですが)

  • ティーカップ
  • タイニー
  • トイ
  • ミニチュア
  • ミニ
  • スタンダード

この中のティーカッププードルという、それはそれは小さくティーカップに入る程の犬・・のはずだったのですが、 よく食べ、よく吠え、壁を噛りながらもすくすくと育った結果、今では普通のトイプードルよりも大きいんじゃないかなというほどに成長しました。 やれやれ。でも可愛いからいいです。

室内温度問題と停電問題

犬を飼った事が初めてだったので、いろいろ勝手がわからず手探りな日々過ごしておりましたが、今年も猛暑が関西を襲いました。 それはそれは暑い夏でした。 そんな暑い日々も、犬のいる部屋だけはエアーコンディショナーが24時間フル稼働でございまして快適な毎日を過ごされておられたわけです。

ただ、エアコン死んだら、まずくね? 部屋締め切ってるよね? 停電とかありえんの? ありえるよね? う〜ん、まずいっしょ。

・・・どうすんの?

ということで、少し悩んだ挙句、 リアルタイムに部屋の温度がわかればいいよね? それをアプリに通知してくれたら、外出しててもなんとかなるよね!ってことで、 作ることにしました。

嘘です。

既に便利なものがありました。

NetAtom社が出している「ウェザーステーション」です。 ウェザーステーション

AppleStoreでも販売してるみたいですね。 Apple Store

製品のポイントとしては

屋内用・屋外用の2つのモジュールがアプリケーションで連動
気温や湿度、CO2濃度などで空気質を評価
iPhoneなどにリアルタイムの空気質アラートを受信
iPhoneからいつでもどこからでも測定値にアクセス
測定値を家族や友人と共有可能
App Storeから専用アプリケーション「Netatmo」を無料でダウンロード
ある場所の天気のパターンを集計するといった使い方も可能

とのことです。 メインは犬の部屋だけでよかったのですが、屋内用だけでは売ってませんでした。

設置とアプリ連携

早速購入して、室内用モジュールと、室外用モジュールを配置します。 AppStoreから[netatom]で検索して、アプリをインストールします。 側ネイティブなのか、動作はややもっちりしてます。 (※2015/11/23にアプリがバージョンアップして見た目が一新されました!!)

f:id:spookies-nishimura:20151125205250p:plain

アカウント作って、自分のモジュールと連携したらいざ確認です。

ふむふむ。

室温はふむふむ、CO2はふむふむ。 といった感じです。

なかなか素敵な感じです。 あとは通知がしっかり出来れば・・。

IFTTTとの連動

そこで、AppStoreからIFTTTアプリをインストールします。 これは、いろんなAPIを紐付けて、

◯が●だったら、△に▲する

というアプリ間連携のレシピを作ることができます。

f:id:spookies-nishimura:20151125205611p:plain

今回は、NetAtomからの情報で、

  • 室温が30℃以上だったら、iPhoneに通知を送る。
  • 室温が20℃以下だったら、iPhoneに通知を送る。

という2つのレシピを作りました。 IFTTTでは、公開のレシピがあったのですが、僕がやった時は何度やってもうまく連携出来なかったので 自分でレシピを作りました。

作るのも簡単です。 NetAtomのアイコン選んで、条件を選んで、通知先を選ぶだけです。

うむ、簡単だね。 無事、通知されるようになりました。

API連携

更にNetAtomでは、APIが用意されていて、室内・室外情報と紐付けていろいろできるみたいです。 これやりたかったのですが、犬の肉球を触っていたら気持よくてまだ手を付けられてません。 Netatmo Developers

まとめ

さて、これで指定の室温以下以上になった場合に通知されるので 安心してスイーツを食べに行くことが出来ます。

意外とおもしろかったのが、CO2濃度です。 特に意識したこともなく、息苦しくなった経験もなかったのですが、 数値と色で警告されると、うーん換気しようかなという気持ちになりますね。 やはり緑は安心する色なのですね。

そして残念なことに、この機器モジュールもコンセントから電源を供給しているので停電になったら通知されません。 それでは、みなさん、ごきげんよう。

GitHub Page に移行して、WordPress をやめました

Hello GitHub Page, Good Bye WordPress.

スプーキーズも9歳になりました。

GitHub Pages f:id:rhymester19:20151026155540p:plain:w300

ということで、以前の記事でも紹介しましたが、サーバ管理も次フェーズに入ったとことで、HPも自社で管理していたWordPress からブログを切り離して、はてなブログに移行し、ようやく静的なページもGitHub Page に移行して、WordPress を廃止しました。

blog.spookies.co.jp

labs.spookies.co.jp

とりたてて技術的なトピックは書くほどのものがないのですが、色々とさわりながら試しながら、とりあえずやってみるっていうのは、楽しいですねー

最近は、やっと少し外にも出れて、Mackerel のMeetUpに参加したり、新しいメンバーが参加したりと、嬉しい刺激を受けています。

筆不精ですぐ更新が止まってしまうのですが、老体に鞭打って発信していきたい思います。

P.S.

いえ、私は村人です。

GitLab 移行の話

Gitlab Slack esa.io AWS Backlog
  • GitLab 移行のお話

久しぶりにネットサービスの海を泳いで爽快な西塚です。

GitLab に Commit 出来ない問題が発生

なんてことはない。Gitサーバのディスク容量が一杯になり、Commitができない状態が発生していました。 ※サーバ管理者としてDiskfullなんてーというツッコミはなしで。

GitLab on AWS

AWSで、Gitlabで運用しているのですが、バージョンも7.6 だったので、7.9にアップデート、ディスクを100GB から、1TBに容量を増やしました。

7.9 では nodejs が入る等、かなりアップデートされているようでしたが、かなり遅くなって、かなり不評でした。

もともと、アクセスが少ないことやコストを考えて、1インスタンスに社内の別のサービスとも同居していて、Ruby が4バージョン(1.8.7, 1.9.2, 2.0.x, 2.1.x)入れた状態で、rvmで切り替えて運用するなんていう七面倒臭いことをしてました。

どのRubyにどのGemがー、なんて適当な私はいつも混乱してたりしたのですが。

1インスタンス1サービス

最近は、メンバーも増えてアクセスの遅さもクリティカルな問題となってきたので、1インスタンス1サービスのような形にしようという方針になりました。

AWSのインスタンスもだいぶ値下げされて、インストールやトラブルシューティングよりもコスパが良いという結論です。

Git に関しては、自社運用以外にもサービスがいっぱい提供されているので、メジャーなサービスも含めて検討しました。

Gitリポジトリサービス選定

GitHub 王道ですね。

BitBucket 何度か利用したことがあり、使い勝手もわかっていたのですが。 Backlog タスク管理はBacklog を利用しているのですが、サービスの利用に容量制限があり、Gitのリポジトリを潤沢に作成することが不安でした。

タスク管理 Issue Tracker

また、Gitのリポジトリと一緒に考えたいのが、他のタスク管理やチャットサービスとの連携です。

個人的には現状では、ただプロダクトの開発を、闇雲に進めるのではなく、仕事として考えて進めるスタイルが良いと考えており、他の Isuue Tracker よりも、一番 Backlog がしっくりきています。

利用サービス全体で検討

また、サービスのベンダーを揃えると、連携がしやすくなるというメリットがあります。

Gitリポジトリ タスク管理 チャット ナレッジ 備考
a BitBucket ○ JIRA ○ HipChat ? Confluence ? Atlassian コンボ
b Backlog △ Backlog ◎ TypeTalk △ Backlog Wiki △ Nulab コンボ
c GitHub ◎ GitHub △ * (Slack ◎) * (Qiita Team ○) GitHub 等メジャー中心構成
d GitLab ○ Backlog ◎ Slack ◎ esa.io ○ Spookies ごった煮

そのサービスが良いか、どうかというものではなく、うちの運用に合っているかという観点で評価をしています。また、コスパも加味しています。

ナレッジに関しては定まっていない感はありますが、Qiita、DocBase あたりをテストしてみて、結果 esa.io に賭けてみようかと考えています。

結局、サーバは移行したけど、巡り巡ってGitlabは変えなかったという話でした。

でも、色んなサービスを久しぶりに触って楽しかった。

良いサービスがあれば、是非教えてください! 是非、情報交換しましょう!

おまけ

サービス連携

別記事で書こうかと思います。

プロジェクト管理

ついでに、Podio、Wrike を使って見ましたが、ピンと来なかったので見送り。