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

esm アジャイル事業部 開発者ブログ

永和システムマネジメントアジャイル事業部の開発者ブログです。

RubyConf Taiwan 2016 に参加してきました

こんにちは。@junk0612です。

12/2 - 12/3 で行われた RubyConf Taiwan 2016 に、弊社から @koic@yucao24hours@junk0612 と、引率の @kakutani の4名で参加してきました。

4泊5日の日程で、旅費はアジャイル事業部の経費から出してもらいました。今日はその様子をお伝えします。

RubyConf Taiwan 2016 Preparty hosted by 5xRuby

前日 12/1 の夜、5xRuby さんが主催した Preparty に参加しました。

海外の方ともつたない英語でお話しさせていただいたり、なぜか途中で Ruby Karaoke が始まって Matz が宇宙戦艦ヤマトを歌っているのを聞いたり、終了後に @JuanitoFatas牛肉麺を食べに連れて行ってもらったりと、たくさん面白い体験ができました。

本編

セッションは英語のものと中国語のものがあって、中国語はさっぱりなので英語のセッションを聞いていました (一応中国語から英語への同時通訳はあったので、聞こうと思えば聞くことはできたのですが) 。

中でも印象に残ったのは「Value And Pain to Keep Rails Applications Alive」でした。Rails 2 から Rails 5 までアプリケーションをアップグレードしていく過程を説明したもので、最初から「そろそろ Rails 5 が出るぞー」みたいな状態だった自分にとっては新鮮な話でした。聞いていると率直にかなり辛そうだということを感じたのですが、周りの先輩方が何度も大きくうなずいているのを見て「本当に辛かったんだな...」と、何とも言えない気持ちになりました。

初日のセッション終了後から Official Party までの 1 時間半ほどの時間を使って LT 大会も開催され、そちらも大盛況でした (7割ほどが中国語だったので内容がほとんど分からなかったのが哀しかった...) 。

f:id:ENIXER:20161202161538j:plain

食事

移動中に「永和豆漿 (ヨンハントウジャン) 」というお店を見つけたので、朝食を食べに行きました。中国語で「豆漿」という単語自体は「豆乳」のことらしいのですが、お店としては「豆乳と選んだおかずで定食が食べられる朝ごはん屋さん」を指すようです (他にも「阜杭豆漿」「世界豆漿大王」といったお店があります) 。

f:id:ENIXER:20161207185502j:plain

実績「永和さんで朝食を食べる」を解除しました!

まとめ

わたしは初めての台湾でしたが、台湾は12月でも20度前後と過ごしやすい気候なのに加えて物価も安く、とても楽しかったです。カンファレンスもいろんな興味深い話を聞けるので、行ってみてよかったなと思いました。

ただ、英語の聞き取りがまだまだだったので話の内容が掴めずに終わってしまったセッションもあり、個人的には今後の課題だなと思いました。英語は使えるようになっておいたほうが何かと便利ですし、おかげで英語に対するモチベーションが上がったので、次のカンファレンスまでには改善して行こうと思っています。

終わりに

永和システムマネジメント アジャイル事業部では、アジャイルな開発を一緒にやってくれる Rubyist を募集中です。今回のように、海外カンファレンスなどの参加費も補助してもらえますので、興味を持った方は アジャイルな開発を一緒にやってくれるRubyistを募集中 - (株)永和システムマネジメント - Wantedly からご一報ください。

調査系タスクの取り組み方について

新卒2年目の tkm_kj です。

ソフトウェア開発をしていると往々にして以下のような課題が出てくることがあります。

  • このツール(ライブラリ)使ったこと無いから技術検証してほしい
  • こんなエラーが起こるんだけど、原因特定できないからしっかり調べてほしい
  • とても性能悪い処理あるから原因特定して改善してほしい

↑のようなものを僕はざっくりと 調査系タスク と呼んでいる(調査した上で改善が込みのものもそう呼んでます)のですが、この手の課題は時間がかかりがちで色々試行錯誤しても求められてる成果が出せないリスクの高いものだと思っています。 過去にズルズルと調査して進捗も芳しくなくまともに共有も出来なかった時は、すごくつらい気持ちになりました。

その状況をなんとかしたいと思って色々試してみた結果、以前よりも少しずつ良い結果を出せるようになってきたと感じています。

そこで、最近意識してる調査系タスクの取り組み方を書きたいと思います。以下の順で書いていきます。

  • 調査に着手する前にしてること
  • 調査中にしてること
  • 調査が終わった後にしてること

調査に着手する前にしてること

目的・完了条件をしっかり明示する

調査をしていくにあたって、目的と完了条件をしっかり把握している状態にしておくことは必須だと思ってます。

技術検証だったら、何のために調べるのか・何がわかれば完了なのかは決めるようにします。

エラーの原因調査だったら目的は明確なのですが、エラーを直すところまでやるのか、エラーの原因を突き止めたところを完了として解決は別途チームで話し合ってから着手するかということを決めます。 性能改善もエラー調査と同じようなアプローチを取っています。

目的と完了条件が曖昧なままだとチームのメンバー間で認識の齟齬が生じやすいですし、着手した時にグダグダになりやすいのでしっかり合意を取っておきたいところです。

調査中にしてること

試したことで上手くいったこともいかなかったことも、自分の手元にメモしていきます。僕はKobitoにメモしてることが多いです。 あくまで自分の手元なので、自分が見たら分かる程度のものです。

調査が進んですごく重要だなと思ったことは、適宜他の人にも見えるところにメモしてます。僕の場合はプロジェクトで ZenHub を使ってチケット管理しているので、GitHubのissueコメントに残してます。

調査が終わった後にしてること

調査が終わったら調査結果をまとめて共有を行います。 その時使っているテンプレート(適宜変えてはいるのですが)があって、

## 目的

(最初に決めた目的・完了条件を書く)

## 結果

(目的・完了条件に書いた内容を満たした結果が得られたのか得られてないのかを簡潔に書く)

## 調査内容

(調べた内容を具体的にまとめる。最終的には結果に書いたところに結びつくようにする)

## 今後の動き

(結果を元に今後どうしていくかを書く)

をベースに書いています。

調査内容に関しては自分の手元に残したメモから重要だと思ったこと、他の人に見えるように残したコメントを引用しながら書くようにしてます。 ここは他のメンバーに読んでもらってフィードバックを頂きたいので、人に読んでもらうということを意識します。

終わりに

以上が僕が最近意識してる調査系タスクに着手する時の流れになります。 とりわけ目新しいことは無いのですが、意識しないと忘れがちになるなーと思い今回書いてみました。 何か参考になりましたら幸いです。

デザインをテストできる Galen をご紹介

til

Galenとは、先月公開された ThoughtWorksTechRadar の Tools で、TRIAL カテゴリに載っていて気になったツールです。

このツールが気になったのは、以下のような説明があったためです。

Testing that layout and styling of responsive websites is working as expected across various form factors can be a slow and often manual process.

ちょうど、そのタイミングで会社メンバーとの雑談で、CSS などをレビューや自分で適用するときにデザインをテストしたいという話題が出ていたので、簡単に試した記録です。

Galen を触る

Galen は、サイトを記述するための DSL 書き、その DSL を実行する環境を JavaJavaScript で記述することになります。

Galen Spec Language と呼ばれるものを使うとサイトの構造を DSL で定義することができるようになります。 このファイルは、galen check コマンドにより、単体でサイト等を指定して実行可能です。

コマンドラインconfigファイルやドライバを渡せば 、コマンドの実行単位でどのブラウザで実行するかを指定できます。 しかし、実際は様々なブラウザで確認したいことが多いでしょう。 そのような時は、JavaScriptJava でコードを記述することで、テストする環境の設定を記述し、まとめて実行することができるようになります。

以下は、JavaScriptFireFoxChrome で、画面サイズを変えながら表示を確認する時のプログラムになります。

var browsers = {
  firefox: {
    browserName: "firefox"
  },
  chrome: {
    browserName: "chrome"
  }
};

forAll(
  browsers
  , function() {
    forAll([
      ["mobile", "400x700"],
      ["tablet", "600x800"],
      ["desktop", "1024x768"]
    ], function (){
      test("Home page on device", function (browser, deviceName, size){
        var driver = createDriver("https://agile.esm.co.jp", size, browser["browserName"]);
        checkLayout(driver, "homePage.gspec", ["all"]);
      });
    });
  });

また、BrowserStack と連携して実行する方法もあるため、IE などのデザインについても自動で確認できるようになります。

所感

ちゃんと全部定義するには大変だけど、デザイン崩れ起こした時のリグレッションや、よくわからないCSSいじる時のテストハーネスに使えそうだなぁという気持ちになりました。 特に、BrowserStack と連携して自動テストができるようになるというのは、Mac などで開発している身としてはとても魅力的という気がします。 test script 内で takeScreenShot というメソッドを使うと、スクリーンショットを取得することが可能になります。 その機能を使い、まずはスクリーンショットをいろんなブラウザで取得し回るだけでも役立ちそうだなぁという気がしました。

24 Pull Requests の紹介

RubyConf Taiwan 2016 に出張中の koic です。今日は年末感あるサービスの紹介です。

f:id:koic:20161130232457p:plain

24 Pull Requests は、12月1日から12月24日までの間に 24 の Pull Request を送るといった年の瀬活動のサービスとなります。

24 Pull Requests の雪降るトップページはこちら⛄️

GitHub アカウントでユーザー認証をします。ダッシュボードでは、ユーザー設定した好みのプログラミング言語に合わせた GitHub 上の OSS プロジェクトがランダムに表示されて、GitHub へのハイパーリンクとなります。多種多様なプラットフォームでの OSS を垣間みる機会にもなりそうですね。

登録後は、こんな感じのプロフィールページから 24 の Pull Request へのスタートです。

f:id:koic:20161201003318p:plain

期間中に Pull Request を出すとこんな感じのアドベントカレンダーになっていきます。

f:id:koic:20161201095655p:plain

一年の感謝を込めて、日頃使っている OSS プロジェクトにフィードバックするきっかけとして、参加してみるのはどうでしょう?

mruby-cli を使ってコマンドラインツールを作ってみた話

til

さて、世間では Advent Calendar が盛んになる時期ですね。

弊社でもやってみればいいのではと思ったものの私自体が存在を思い出したのが 11/30 なので、 何も調整せずに勝手に書き出してみて、誰かが続いて書いて 25 日まで続いたらいいなーと思ってはじめてみることにます。 (このブログは、強制だったりノルマがあるわけではなくメンバーが書きたくなったら書くというゆるいルールでやっています。)

本題

もう 1 ヶ月ほど前になりますが、mruby-cli を使って個人で使うツールを作っていました。

今回、なぜ mruby-cli を使用したかというと、よく使うコマンドはワンバイナリでインストールできる形の方が扱うのが簡単と思ったのと、クロスコンパイルで複数の環境のバイナリを普段書き慣れている Ruby で生成できるという点を魅力的に感じたからです。

そこで、普段 CRuby を使っている人が mruby-cli でアプリケーションを開発してみた時に感じた気づきについてまとめてみたいと思います。

mruby は CRuby で使えるメソッド全てが使えるわけではない

書き出して最初に意識を変えないといけないと思ったポイントです。mruby は、CRuby で入っている標準ライブラリのメソッドが全部あるというわけではありません。

String や Array など標準ライブラリにあるメソッドでも、mruby における Rubygems 相当の mgem を使って拡張する必要なものがあります。

mruby で利用するライブラリは mruby/mgem-list から探す

次に困ったことはライブラリはどこから探せばいいかということです。 CRuby であれば rubygems.org で探すことができます。

mruby/mgem-list という有志が作っている mgem の一覧から探すようです。

require する必要がない

mruby-cliRuby で書くのですが、ファイルを分割した際、明示的に require をする必要がありません。

動かすにはコンパイルが必要

すごく当たり前のことなのですが、動かす時にコンパイルする必要があります。 今回、REST API を叩くコマンドライブラリを作成していたのですが、API の使い方やレスポンスの内容などを作成しているアプリで try & error でやろうとすると大変という印象を受けました。

最後に

同じ Ruby の文法といっても、ライブラリの探し方から実行させるための手順が違い戸惑うことが最初のうちは多かったです。しかし、Web サービスのクライアントアプリを書くという範囲では、1 つでも API を叩くパスが出来てしまえば、あとはサクサク進むという印象でした。

ツールを作る手段として、覚えておいて損はないと思うので素振りしてみるといいと思いました。

bundler にサブコマンドを追加する

til

TL;DR

bundle-#{sub_command_name} というコマンドを作り PATH が通っている箇所に配置をすると bundle sub_command_name で呼ぶことができる。

本文

先日、X 回目の Rails Update 業を行いました。 今回の Rails Update 業は、久しぶりに再開したプロジェクトのため Rails 以外の gem から出されている deprecate warning を消すのに苦労しました。

その際、何のメソッドが呼ばれたことによって deprecate warning が出るのはわかっているので、bundler に入れている gem 群を grep できたらと思いました。

これを実現するには、以下のようなコマンドの組み合わせで実現できます。

$ bundle show --paths | xargs grep keyword

これを bundle grep keyword のように書けたらべんりだなーって思い、bundler のコードを読み実現できないかを調べてみました。

そこで見つけたのが、Bundler::CLI にある以下のコードです。

def self.handle_no_command_error(command, has_namespace = $thor_runner)
  if Bundler.settings[:plugins] && Bundler::Plugin.command?(command)
    return Bundler::Plugin.exec_command(command, ARGV[1..-1])
  end

  return super unless command_path = Bundler.which("bundler-#{command}")

  Kernel.exec(command_path, *ARGV[1..-1])
end

これを見ると、bundler 自体がサブコマンドとして用意していないサブコマンドは、bundler-#{command} というコマンドを探し、存在していたら実行してくれるように読めます。

そこで、bundler-grep という、gem を作ってみました。gem i bundler-grep して、環境変数などをセットすれば、お好きな grep コマンドで bundle show --paths 内を grep できるようになります。

余談

これを作っている最中に、それワンライナーでできるよと bundler に pull request 出してた人 から言われたため、このワンライナーだけではできない機能も入れたりしました。

RubyWorld Conference 2016 に参加しました

こんにちは、 @junk0612 です。

11/3(木・祝) と 11/4(金) に島根県松江市で行われた、RubyWorld Conference 2016 に参加してきました。 今回は総勢9名での参加となりました。

Platinum スポンサー

RubyKaigi 2016 でも スポンサーをさせていただきました が、今回も Platinum スポンサーとしてブース出展をしてきました。

前回のアジャイル阿闍梨餅に引き続き、今回も地元の和菓子ということで 福田屋 さんにお願いして、Ruby に見立てた赤い寒天が特別に乗った紅白のお饅頭をブースにて配布しておりました。(紹介してくださったスーパー公務員の皆様、ありがとうございます!)

ショートプレゼンテーション

協賛企業ショートプレゼンテーションとして @koic が「10年生きる Ruby/Rails アプリケーションプログラマーのエコシステム」というプレゼンをさせていただきました。

www.slideshare.net

コーヒーブレイクの時間でのプレゼンテーションでしたが、来ていただいた方とお饅頭を片手にお話ができ、興味を持っていただいたようで良かったです。

セッションの感想

わたしは今回初めての参加でしたが、「小さな町で子供向けのプログラミング講座をはじめてみて」や「ゼロから稼げるエンジニアになる3つのステップ」など、RubyKaigi では聞くことができなさそうなセッションにも参加できて、新鮮で面白かったです。

また、「Scientific Computing in Ruby」の直後に「Ruby における機械学習のための環境整備の取り組み」という機械学習トピック2本立てのセッションが強く印象に残りました。 Python で scikit-learn を用いて、ランダムフォレストを使った分類などのかんたんな機械学習を学生時代に少しかじったことがあるのですが、Ruby でもそれができるようになるといいなぁ...(そこに貢献することができたらもっとうれしいですね)

さいごに

今回のカンファレンスは非常に充実した時間を過ごすことができました。これも運営に携わっていた皆様や発表者の皆様のおかげと存じます。 また、ブースに立ち寄ってくださった皆様、ショートプレゼンテーションで興味をもってくださった皆様ありがとうございました。またどこかのスポンサーブースで (和菓子を用意して?) お待ちしております!