Slackに特定ブランチへのpushを通知する

2015年12月20日
区分
報告者:
komatsu

こんにちは、komatsuです。

日付が変わってしまいましたが、この記事はアクトインディ Advent Calendar 2015の19日目の記事です。ネムイ(´・ωゞ)

翌20日目の記事は、hondaによるAndroidアプリ開発用のCI環境を作ろうです。

さて、弊社ではチケット管理にRedmineを使っていて、 新機能開発などの大きめのチケットには、Slackにそれ専用のチャンネルが立つことがあります。 (メンバーはそのチケットの担当プログラマ、デザイナ、ディレクタ)

ですが、

  • (ディレクタはGitHubのcommit logを見ないので)バグ対応などの細かいタスクの進捗を報告するのが面倒
  • 特に話し合うことが無いと更新が全くなくて若干寂しい

という個人的な問題がありました。 なので、そのチケットに関連するブランチへのpush内容をチャンネルに通知できたら、上記の問題が多少改善するのでは?と考え、このようなコードを書いてhubotに反映してみました。

(onで通知するブランチを登録できて、offで解除できます。)

直近の大きめチケットで実際に運用してみましたが、個人的には上記の問題は改善された気がしています。

できるだけ手間をかけずに情報共有できたらいいですよね。

それではみなさん、より良い開発環境を!

出社したらSlackで自動的に挨拶する

2015年12月11日
区分
報告者:
komatsu

こんにちは、komatsuです。

この記事はアクトインディ Advent Calendar 2015 の11日目の記事です。 前日の記事がハードコアだったので今日は軽いものを。

さて、弊社では週2日程度のリモート勤務が認められています。 リモートだと居るかいないかが特に分かりづらいためでしょうか、勤務開始時にSlackで挨拶をするのが習慣になっているようです。 が、別に出社しているときでも挨拶はしてよいもののはずです。というかリモートからは社内の様子が分かりにくいので、リモートであろうとなかろうとSlack上で挨拶してくれればいいのになーと思っています。

(※ 勤務開始時間は自由に設定できるため人によってバラバラ)

というわけで出社のときでも挨拶するように個人的に心がけているのですが、出社している安心感からかどうしても忘れがちでした。 忘れないためにリマインドするのも悪くはないのですが、いっそ忘れてもいいように自動化してしまいたいところです。

やってみる

出社時間はまちまちなため、社内の無線LANに入ったときをきっかけにしてSlackに挨拶を投稿すればよさそうです。

SlackのTokenを取得

プログラムからSlackに投稿できるように、Tokenを取得します。 https://api.slack.com/web のAuthenticationでCreate tokenすればokです。

スクリプトを作成

こんな感じ(↓)の雑なスクリプトを書いて ~/hello に置きました。 Wi-Fiの接続先が会社のものだったときに、1日1回まで挨拶をSlackに投稿します。

# 1日1回 
require 'date'
path = '/Users/nomnel/hello/last'
return if File.exists?(path) && Date.parse(File.read(path)) == Date.today
 
= `networksetup -getairportnetwork en0`.match(/Current Wi-Fi Network: (.+)/)
return unless x
ssid = x[1]
if %w(office).include?(ssid)
  params = { 
    token: 'ここにToken',
    channel: '#general',
    text: 'おはようございます',
    as_user: 'true',
  }.map {|k, v| "#{k}=#{v}" }.join('&')
 
  require 'uri'
  url = "https://slack.com/api/chat.postMessage?#{URI.encode(params)}"
  `curl "#{url}"`
 
  File.write(path, Date.today.to_s)
end

launchdで自動実行

~/Library/LaunchAgents/hello.plist を作成し、中身を以下のようにします。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>Hello</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Users/nomnel/.rbenv/shims/ruby</string>
    <string>/Users/nomnel/hello/run.rb</string>
  </array>
  <key>StartInterval</key>
  <integer>60</integer>
</dict>
</plist>

あとは launchctl load ~/Library/LaunchAgents/hello.plist して読み込んでおき、 出社してPCを開けば…

えびでんす

できましたね!

最後に

アクトインディではとりあえず自動化したがる横着なエンジニアを募集しています!

RubyKaigi2014 1日目レポート

2014年09月23日
区分
イベントレポート
報告者:
komatsu

9/18~20に開催されたRubyKaigi2014に、弊社からはエンジニア4名中3名(kawaguchi, oishi, komatsu)が参加費は会社持ち+期間中は出勤扱いで参加しました。 なお弊社ではおでかけ先探しに悩むパパ・ママを助けてくれるエンジニアを募集しています!

さて、私komatsuからは初日18日のレポートをさせていただきます。

CRuby Committers Who's Who in 2014 [JA]

発表者: Tomoyuki Chikanaga

  • コミッターはbotも含めると84アカウント
  • 今回のKaigiで発表する方15人に絞って紹介
  • 紹介内容はこちらのブログ参照

Building the Ruby interpreter -- What is easy and what is difficult? [JA]

発表者: Koichi Sasada

全て書くと多すぎるので詳細はこちらを見ていただくとして。

個人的にはトレードオフを考えつつ、トレードオフに打ち勝つような道を探すという話が印象に残っています。

Symbol GC [JA]

発表者: Narihiro Nakamura

資料

  • SymbolはGCされないので、ユーザ入力をSymbol化しているとメモリ使用量が増加し続ける脆弱性がある
  • Symbol GC導入後でもGCされるSymbolとGCされないSymbolがある
  • 前者(GCされる)をMortal Symbolと言う。'sym'.to_symなど
  • 後者(GCされない)をImmortal Symbolと言う。メソッド名など
  • Mortal SymbolはImmortal Symbolになりうるが逆は無い
  • ユーザ入力をメソッド名として使っていると上記の脆弱性は解消されないので注意

Continuous Delivery at GitHub [EN]

発表者: Robert Sanheim

会場が超満員だったので入り口付近で音声だけ…。

もちろん資料も見えないし英語も全く聞き取れなかったので、Twitterを見てどんな話をしているか理解しました。

  • Continuous Deliveryやれよ
  • あるブランチが長期間存在してるのは良くない、早めにマージできるようにするべき
  • GithubでRailsを3に上げたときは、最初はブランチを切っていたけど長くかかり過ぎたのでmasterで作業した(?)
  • ↑のときはRailsのバージョンでコードを分岐させた(個人的にはそれはそれでつらそうだった)

What's wrong with your app? [EN]

発表者: Keiko Oda

  • Herokuのメンバーいっぱい来てるから見つけたら遠慮なく話しかけてね
  • Herokuでよく見るエラーの対処法とか
  • LoggingとMonitoringしましょう

Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby) [JA]

発表者: Satoshi Egi

  • Egisonの作者さんの発表で、Egisonパターンマッチの一部をRubyに持ち込んだ話
  • egison-rubyを作った。これによりRubyはnon-linear pattern-matchingの出来る2つ目の言語になった
  • ポーカーの役を判定するパターンマッチ
  • 自分でも書いたことあるけど、明らかに理解しやすいコードになってた
  • 個人プロジェクトで使ってみたいけど、そもそもパターンマッチってどんなところで使うんだろうか、調べてみよう
  • 質疑応答1 Q. 速度は問題ないか A. 大丈夫じゃないかな
  • 質疑応答2 Q. 習熟までに要する時間は A. 東大生で3時間、同僚は3日間

Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails [JA]

発表者: Toru Kawamura

資料: http://www.slideshare.net/tkawa1/rubykaigi2014-hypermedia-the-missing-element

  • 今までのWeb APIは操作とURLが密結合していて変化に弱かった
  • 変化は避けられない、Web APIは変化に適応しなければならない
  • 例: FizzBazzaaS
  • クライアントは、URLとパラメータを用意してAPIをコールするのではなく、レスポンスに含まれるリンクを選ぶ(=Hypermedia)
  • すでにHTMLで実現されている(リンク、フォーム)
  • さらに、検索エンジンのクローラはこの部分がレビューだとどうやって判断しているのか -> Microdata
  • Microdataを使うことでHTMLの意味を表現することが出来る
  • HTMLをWeb APIに使えるのでは
  • でもJSON使いたいよね -> HTMLからJSONに変換するgem作ったよ > Hypermicrodata
  • Microdataだけじゃなく、リンクとフォームもHTMLから抽出する
  • WebアプリとWeb APIを分けて考えない、同じように設計する

"Gem of this Week" - building culture and making gem [JA]

発表者: Takumi Miura

資料: https://speakerdeck.com/mitaku/rubykaigi-2014-gem-of-this-week

  • geminaboxを使ってprivateなGemをホスティングしている
  • 共通化出来そうなものはどんどんGemに
  • Gemを作る文化を育てている
  • 今週のGem、という企画があって良かったものを表彰している
  • drecom_gemで社内用Gemの作成を簡単に
  • GemnasiumをインスパイアしたGemicomを使ってgemの更新をチェックしている
  • 最新バージョンのgemを使っているかをランキング化している
  • 社内ツール開発サークルがある

Ruby committers vs the World

まとめきれないので詳しくはToggeterを見てください

  • Q. Ruby3.0に入れたい機能は A. Matz「明日(はぁと」
  • インデント整えるのは別のコミットにわけてほしい、本当にインデントだけを変えたのか確認しないといけない
  • Rubyにマクロは入らない、(neverは使わないで答えて、と言われて) absolutely not.
  • true.! # => false
  • etc...

個人的感想

  • 一日中イスに座って話を聞いてお尻が痛くなったりもしましたが、知見に溢れた講演ばかりでRubyを書きたい欲求が大いに刺激た
  • 今までTwitter上で眺めるだけだったRubyistの皆様と話すことができて、「場」を共有することの大きさを痛感させられた
  • Rubyコミュニティから恩恵を受けるだけでなく、貢献していけるようになりたい

月並みな感想ですが1日目のレポートは以上とさせていただきます。

最後に

繰り返しになりますが弊社ではおでかけ先探しに悩むパパ・ママを助けてくれるエンジニアを募集しています!

席替えしました

2014年04月28日
区分
社内環境
報告者:
komatsu

はじめまして、昨年11月(oishiの1週間後)に入社したkomatsu(nomnel)です。入社前は1年半程ニートを満喫していました。
(ところで、そんな私がRailsプログラマとして働けているのも弊社元役員が起ち上げたFjord社のインターンのおかげです、お世話になりました。)

さて先日、弊社制作チーム(プログラマ、デザイナ、コーダ、ディレクタ)で席替えを行いました。
というのも、歴史的経緯からプログラマが端と端に分断されていたからです。

業務連絡はSkypeで行っているのですが、それとは別にちょっと話したいときでも席を立たなければならないのは非効率で、早急にデフラグが必要でした。
当初は

のようにプログラマをまとめるだけのつもりでしたが、taharaのこの発言により

のような形になりました。(十字型だったがモニタへの映り込みが気になるとのことで移動)
なおディレクタ横の空席は、ディレクタへの相談や、偉い人がディレクタをしごきに来るときに利用されています。

この席替えにより、

  1. ちょっとした相談をしやすくなった
  2. 対面に人が居ないので以前より集中できるようになった
  3. プログラマミーティングのときにわざわざミーティング用スペースに移動しなくてすむので楽
などの効果を感じれたようです。(サンプル数: 1)

スペースは以前より使ってしまいますが、まだ文句は言われていないので多分大丈夫なんでしょう。

というわけで、自分たちが働きやすい環境を自分たちで作る活動の一例でした。
(※ 他にもオフィスドーナツの導入を目論み中です)

技師部隊からの
お知らせ

【求人】エンジニア募集しています。

本頁の来客数
八十七万千百七十六名以上(計測停止中)

メンバー一覧

アクトインディ技師部隊員名簿

アクトインディ技師部元隊員

アクトインディへ

カテゴリー

アクトインディ

aaaa