東京30K秋大会を走ってきた

毎年10月に開催されている東京30K秋大会に今年も参加し30kmを走ってきました。

f:id:miyohide:20171007223625j:plain

自身の結果

タイムは2:38:15。自己ベストでした。昨日の夜から雨が降り続き、レース中は小雨から曇りになったとは言え、足元が悪い中自己ベストを出せたのは出来過ぎ。ただ、ラスト5kmはかなりしんどかったので、今月末に走る横浜マラソンに対しては若干不安を覚える結果となりました。

5kmごとのラップタイムは次の通り。

距離 ラップ 備考
0km - 5km 26:27 ちょっと早い感じ
5km - 10km 28:27 途中でトイレに入る
10km - 15km 26:41 たまたま近くにいたペースメーカーについていく。風が強く吹いていた
15km - 20km 25:01 風向きが変わったので、ペースを上げて元々のペースメーカーに追いつくようにする
20km - 25km 25:38 22km地点でペースメーカーに追いつく。
25km - 30km 26:01 何とかペースを維持したままゴール

ペース上げ下げが激しいですが、よくもってくれました。

大会の特徴

この大会の特徴は、細かいペース設定ごとにペースメーカーが付いて2分間間隔でのウェーブスタート制という点。その日の体調に合わせてスタート位置を変えられるので、自己確認の場としてかなりいい大会です。

そのためか、参加者もかなり多い大会です。特にトイレの数は全然足りないので、早め早めの行動を心がけたほうが良いと思います。

mruby-mrbgem-templateを使ってmrbgemをつくる方法

はじめに

唐突に mrbgem を作りたくなる時、ありますよね。そんな時、なにかいい方法無いかなと思ったら @matsumotory さんの mruby-mrbgem-template というものが非常に便利だったので備忘録がてら使い方を記します。

環境

  • OS X El Capitan
  • mruby 1.3.0
  • mruby-mrbgem-template commit cb5c0a3887d(2017/10/4時点の最新バージョン)

使い方

導入

mruby を取得する

おそらく master でもよいのですが、バージョンを明確にしたかったので mruby 1.3.0 を取得して build することにしました。

$ wget https://github.com/mruby/mruby/archive/1.3.0.zip
$ mv 1.3.0.zip mruby-1.3.0.zip
$ unzip mruby-1.3.0.zip
$ cd mruby-1.3.0
mruby-mrbgem-template のインストール

mruby-1.3.0/build_config.rb を編集し、mruby-mrbgem-template を使用する gem として追加します。具体的には次のように編集します。

MRuby::Build.new do |conf|
  # load specific toolchain settings

  # Gets set by the VS command prompts.
  if ENV['VisualStudioVersion'] || ENV['VSINSTALLDIR']
    toolchain :visualcpp
  else
    toolchain :gcc
  end

  enable_debug

  # Use mrbgems
  # conf.gem 'examples/mrbgems/ruby_extension_example'
  # conf.gem 'examples/mrbgems/c_extension_example' do |g|
  #   g.cc.flags << '-g' # append cflags in this gem
  # end
  # conf.gem 'examples/mrbgems/c_and_ruby_extension_example'
  # conf.gem :core => 'mruby-eval'
  # conf.gem :mgem => 'mruby-io'
  # conf.gem :github => 'iij/mruby-io'
  # conf.gem :git => 'git@github.com:iij/mruby-io.git', :branch => 'master', :options => '-v'
  # ↓↓↓ 追加
  conf.gem github: 'matsumoto-r/mruby-mrbgem-template'
  conf.gem '../mruby-nmea'
  # include the default GEMs
  # (以下省略)
mruby の build

mruby を build します。単純に rake コマンドを実行するだけです。

$ rake
create.rb の作成

mruby-1.3.0 の直下に create.rb を作成します。中身は、次の通り。paramsの各値を編集します。

params = {
  :mrbgem_name    => 'mruby-example',   # mrbgemの名前
  :license        => 'MIT',             # ライセンス
  :github_user    => 'miyohide',  # GitHubのユーザ名
  :mrbgem_prefix  => '..',   # mrbgemのディレクトリのパス
  :class_name     => 'Example',  # 生成するクラス名
  :author         => 'miyohide',  # 作者名
}

c = MrbgemTemplate.new params
c.create
雛形作成

これでmrbgemの雛形をつくる準備が整ったので、

$ ./bin/mruby create.rb

を実行すると、mrbgemの雛形が作られます。上記のようにcreate.rbを設定すると、

[~/work/mruby-1.3.0]$ ./bin/mruby create.rb
Generate all files of mruby-example
create dir : ../mruby-example
create dir : ../mruby-example/src
create file: ../mruby-example/src/mrb_nmea.c
create file: ../mruby-example/src/mrb_nmea.h
create dir : ../mruby-example/mrblib
create file: ../mruby-example/mrblib/mrb_nmea.rb
create dir : ../mruby-example/test
create file: ../mruby-example/test/mrb_nmea.rb
create file: ../mruby-example/mrbgem.rake
create file: ../mruby-example/Rakefile
add gitignore entry: ../mruby-example/.gitignore
create file: ../mruby-example/mruby-example.gem
create file: ../mruby-example/.travis.yml
create file: ../mruby-example/.travis_build_config.rb
create file: ../mruby-example/README.md
create file: ../mruby-example/LICENSE

  > create miyohide/mruby-example repository on github.
  > turn on Travis CI https://travis-ci.org/profile of miyohide/mruby-example repository.
  > edit your mruby-example code, then run the following command:

  cd ../mruby-example
  git init
  git add .
  git commit -m "first commit"
  git remote add origin git@github.com:miyohide/mruby-example.git
  git push -u origin master

  > finally, pull-request mruby-example.gem to mgem-list https://github.com/bovi/mgem-list

[~/work/mruby-1.3.0]$

という実行結果が出力され、mrbgem_prefix + / + mrbgem_name なディレクトリが作成されます。

あとは実装とテストを書くだけ

あとは、mrbgem_nameで指定したディレクトリに移動して、CやRubyで実装を書くだけです。mrblibディレクトリやlibディレクトリにそれぞれRubyとCでの実装を書き、testにテストを書くみたいです。

また、作成した直後でも rake test を実行することでテストを動かすことができます。

[~/work/mruby-example]$ rake test
git clone --depth=1 git://github.com/mruby/mruby.git
Cloning into 'mruby'...
(省略)
             mruby-example
             mruby-bin-mrbc - mruby compiler executable
             mruby-test - mruby test
================================================

>>> Test host <<<
(省略)
Total: 959
   OK: 959
   KO: 0
Crash: 0
 Time: 0.1 seconds
[~/work/mruby-example]$

RubyKaigi 2017にてLT発表をしてきました

はじめに

RubyKaigi 2017にてLT発表をしてきました。このエントリーは発表の概要とその他雑多な感想を記します。

f:id:miyohide:20170921213344j:plain
タイトルをTypoしているのに全然気が付かないぐらいに緊張していた...

LTの内容

LTの内容として、RubyistMagazine、通称るびまの過去資産であるhikiMarkdownに変換する話をしました。技術的にはそんなに複雑なものではないのですが、色々なパターンが有り地味に大変でした。

今のところ、最新号までのMarkdown化までは終わり、jekyll serverで起動すればお手元の環境でるびまが動きます。

反響

LT発表中に「5,000m」というところを「5,000km」と言ってしまったことで爆笑をかっさらい、その後の懇親会等々でも色々お声がけ頂きました。狙ったわけではないんですが、いいネタになったようで怪我の功名といったところでしょうか。

また、「るびま、手伝いましょうか?何か手伝えることがありますか?」って多くの方々からお声がけを頂いたのですが、さっと出せるものがなく、なんとも勿体無いことをしてしまいました。ざっと上げてみると、

思えばたくさんあります。が、これら全部が全部私の頭のなかにあるだけなので、どこかで棚卸しをしないといけない。まぁ、一歩一歩やっていきます。

RubyKaigiに行く意味

毎年RubyKaigiに行っているのですが、去年から首都圏以外で開催されるようになってから行く目的をしっかり持つようになりました。スライドは大方公開されますしセッション動画もすぐ公開されるRubyKaigiにおいて、現地に出向く意味です。え?5,000km走るんでしょってことではなくてですよ。

そのためにCFPを出したり(出すためのネタを作ったり)、知らない人と話をするというのを今回の目標としました。自分の中では結構上手く出来た感じ。ただ、新しい課題も見えてきていて、

  • Rubyだけじゃなく、もっと色々な言語に触れておくべき。Goとか。多分一つの言語・フレームワークで戦える時代ではない。
  • 実戦大事。実際に自分がやったことの話が一番説得力ある。
  • 英語はまぁ、長年の課題ですね。はい。

来年は5月末に仙台で行われると言うので、それまで何らかの結果を出したいです。

ここ最近の技術系メモ(2017年5月版)

はじめに

ちょっと油断するとブログを放置してしまい、過去に色々と調べた内容は喉元過ぎれば熱さを忘れるごとく、綺麗サッパリと忘れてしまって再度問題にぶち当たるとまた調べなおすのが辛かったので、ちょっとまとめてみることにします。

form objectを使ってみよう - メドピア開発者ブログ

メドピア開発者ブログから。個人的には、viewのなかで○○_tagってものが出たら危険なサインだと思っています。

著者さんのサイトで補足も書かれているので合わせて読むとよいかと。

blog.willnet.in

Rails Developers Meetup #1(東京会場) - connpass

5月18日(木)に『Rails Developers Meetup #1』が開催されました。残念ながら参加できなかったのですが、スライドは以下で公開されています。

rails-developers-meetup.connpass.com

「ふつう」のRuby on Rails ウェブサービス開発(Clipla x みんなのウェディング) - connpass

5月23日(火)に『「ふつう」のRuby on Rails ウェブサービス開発』が開催されました。スライドは以下で。

mwed.connpass.com

岩崎さんの『ふつうのRails開発を続けるために』の「ご利用は計画的なGem」についてはドキリとさせられました。

関西Ruby会議2017

5月27日(土)に『関西Ruby会議』が開かれました。残念ながら参加できなかったのですが、スライドは公開されていますので、目を通しておきたいです。個人的に興味深い「エンタープライズRubyOnRails」のスライドが公開されていないのがちょっと痛い...。

後日、開催レポートがるびまに寄稿されるはずなので、それを楽しみにしながら。

DSAS開発者の部屋:大幅にパワーアップした「ESP32」で mruby を動かす

ひょんなところからESP32というものを紹介していただき、ちょっと試してみているのですが、色々と勝手が違って思うように動かない。サンプルプログラムのHello World!がでないのはちょっとつらい。。。

まとめ

今までは気になった記事などはPocketとかに登録しておいてそのまんま放置ということが多かったのですが、今回こういう記事を書いてみて、良い棚卸しができたような気がします。幾つかのブログやスライドも目を通すことができたし。

いつまで続けられるか分かりませんが、ちょっと頑張ってみようかと思います。

Strength Finder 2.0をやってみた

私の周りでStrength Finderが流行っていたので、自分も本を買ってやってみました。10年ぐらい前にやった覚えがあるのですが、結果なんて全然覚えていないし、2.0にバージョンアップしたということも有って、新しくトライ。

書店でも本が平積みされていて売れているようです。

結果としては、

  1. 分析思考
  2. 調和性
  3. 慎重さ
  4. 公平性
  5. 学習欲

がTop5として出てきました。大体納得できる感じ。

おおむね、慎重すぎるきらいがあるので、もうちょっと積極的に行く必要があると思っていて、最近特にそういうことを感じています。

『世界で闘うプロダクトマネージャーになるための本』を読んだ

今年に入ってから続けている朝読書の時間を利用して、長らく積読であった『世界で闘うプロダクトマネージャーになるための本』を読み終えました。

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~


最初、本書を手に取ったとき、「あ、プロジェクトマネージャーじゃないんだ」ということに気がつきました。仕事ではPM=プロジェクトマネージャーを指す用語であって、プロダクトマネージャーという言葉はあまり聞いたことがありませんでした。プロダクトマネージャーとプロジェクトマネージャー。似ている言葉だけど本書の中では、

プロジェクトマネージャーの主な仕事はスケジューリングと調整です。プロジェクトに対する要求の取りまとめに責任を負うこともありますが、要求を特定したり選択したりする際に意見をいうことはあまりありません。

プロダクトマネージャーの責務は、問題点とチャンスを特定し、そのうちのどれを追求するかを選び、その後はチームが優れたソリューションを見つけられるようにすることです。

という風にその違いを述べていて(P20)、なんとなく違いが分かるようになりました。

そういうふうに漠然とした言葉の定義はあるにしても、様々な企業でプロダクトマネージャーに求められることがそれぞれ違うことに驚きました。詳細は本書の第3章に記されているのですが、多種多様でそれぞれの企業の規模や文化によってこうも違うのかと驚きを持って読み進めた。

7章からはプロダクトマネージャーとして採用されるために様々な点での対策が記されています。レジュメの書き方から企業研究、面接時にあるであろう各種質問への考え方や答え方などです。非常に詳細にかかれていて、プロダクトマネージャーを目指さなくても良い対策になるのではと思いながら読み進めることができました。

個人的には、第7章からの記述が大変具体的で、自分ならレジュメをどう書くかとか、出された問題に対してどのように答えを導き出すかについて考えるのが大変楽しく、プロダクトマネージャーを目指さなくても自分の業務経歴の棚卸しだったり面接練習になったりして楽しく読み進めることができました。

Ruby Business Users Conference 2017に行ってきた

はじめに

2017年2月23日(木)に渋谷で開催されたRuby Business Users Conference 2017に行ってきました。会場は、数年前渋谷Ruby会議が開催されたシダックスカルチャーワークスでした。

f:id:miyohide:20170223235900j:plain

技術系の話がメインではなく、Rubyを使ってどのように仕事をしているかを紹介するカンファレンス。毎年11月に島根で行われるRubyWorld Conferenceの東京版と言った感じです。

プログラム

プログラムは

  • Matzによる主催者講演『Rubyサバイバルガイド』
  • 安川 要平氏による『子どものためのプログラミング道場「CoderDojo」を支えるRails CMSの活用事例』
  • 森 雅智氏による『TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り』

www.slideshare.net

  • 伊藤 浩一氏によるLT『Railsアプリケーションプロジェクトでの読み書きそろばんの1周目、2周目とそれから』

www.slideshare.net

  • 堀井氏によるLT『Rubyとスタートアップ』

speakerdeck.com

  • 村田 賢太氏による『Rubyにおける機械学習のための環境整備の取り組み』

speakerdeck.com

  • 川崎 禎紀氏による『Rubyを大規模に使い続けるのは難しい? - Wantendly5年間のアーキテクチャの変遷と改善の歴史 -』
  • 木村 圭宏氏による『プログラミングスクール卒業生による受託開発サービス立ち上げとその課題』
  • Rubyアソシエーションによる『Rubyアソシエーション活動紹介』

という構成でした。

休憩時間が頻繁に取られコーヒーの無料サービスもあったことから終始リラックスして話を聞くことができました。

各プログラムのメモ

以下はそれぞれのプログラムについてメモを書き下ろします。

Matzによる主催者講演『Rubyサバイバルガイド』

  • Rubyをどうやってサバイバルしていくかという話。
  • ソフトウェアなのでハードウェアのような摩耗による故障はないが、老化はある。
    • OSが提供するAPIの変化に対応できないなど、周りの環境の変化についていけないことが老化の一つ。
  • RubyはWebアプリフレームワークRailsの登場を契機に主要な言語の一つとなった。
  • Webアプルは年々巨大化
    • 巨大化とは「コードの量」、「アクセス数」、「データ量」それぞれのことを指す。
    • それらに対応するためにスケーラビリティーが求められている
    • また、フロントエンドが複雑化している
  • 他にもRailsがカバーしないモバイルアプリやデータサイエンス、IoTなど色々とソフトウェアが求められる場所が多くある。
  • スケーラビリティーに対してRubyはコンカレンシー、パフォーマンス(最適化)、開発支援などでサバイバルしていく
    • コンカレンシーはマルチコアを活かせるように。例えば、ギルドの導入とか。
    • パフォーマンス(最適化)はJITを。
    • 開発支援はコンパイル時のチェックや静的チェックなど。
  • フロントエンドの複雑化については、Ruby->JavaScriptOpalやOpalを採用しているVolt Frameworkを紹介
  • データサイエンスはSciRubyプロジェクト
  • IoTはmruby
    • スクエニの新作ゲームにも組み込まれているらしい。
  • 質疑応答にて、「Ruby3の互換性は極力維持する方向で考えている」とのこと。

安川 要平氏による『子どものためのプログラミング道場「CoderDojo」を支えるRails CMSの活用事例』

  • 子どものためのプログラミング道場「CoderDojo」のサイトについてどのような作りになっているかを紹介
  • 当初はGitHubでWebページを作成していったが、デザインの改善や様々な要望に答えるためにAngularやParseなどを使ったサイトに移行。
  • Parseの終了やページのContributorが自分以外に居ないことからRailsscrivitoを使ったCMSを構築。
  • 結果、Contributorは12名まで増え、「CoderDojo」の成長を支援している。

森 雅智氏による『TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り』

  • 技術ブログ「TechRacho」をどのような思いで続けているかの紹介。
  • 技術情報発信は2016年8月から事業化して平日毎日更新していること。
  • 事業化する前は、(最近の会社の成長で発生した)次のような問題に対する対処のため。
    • 社内の雰囲気や文化の継承が難しく、コミュニケーションが円滑に行えなくなる
    • 新しく入社する人が増えると一時的に開発の出力が低下してしまう
    • 熟練者のスキルアップが難しい
  • 事業化してからは、
    • 記事の社内レビューを実施し、社内エンジニアの技術力向上が図れている
    • 記事化することで流れてしまうチャットの情報を再利用することができている
    • 続けるのは大変
    • 計測可能な指標が取れていない(はてブの数とかはそんなに変わっていない)

村田 賢太氏による『Rubyにおける機械学習のための環境整備の取り組み』

  • 統計分析や機械学習の各種用語の説明から。
    • 人間が介在する統計分析と人間が介在しない機械学習
  • Rubyではデータサイエンスはできない。
  • その理由は以下の3点。
    • 道具がない
      • 正確には道具はあるが、実用的ではない。
        • 機能が足りない
        • 道具間の連携が困難
        • 品質が信頼できない
    • 使っている人が居ない
      • PythonやRを使っている人が多数
      • PythonやRを使ったデータサイエンスの求人が多い
    • 作ろうとする人が居ない
      • 作ることが目的の人が少ない
      • 使う人と作る人のそれぞれのスキルセットは別
  • この負のスパイラルから脱却するためにRubyのためのデータサイエンス環境作りを行っている
  • RubyからPythonやRの資産を使えるようにする
  • PyCallの紹介とデモ
  • itocに記事(『データサイエンスにおけるRubyの現在の位置づけと可能性』)も書いています。

www.s-itoc.jp

川崎 禎紀氏による『Rubyを大規模に使い続けるのは難しい? - Wantendly5年間のアーキテクチャの変遷と改善の歴史 -』

  • 5年間でIssue/Pull Requestは29K
  • 185K行のプログラム
  • モデル数は402
  • Railsでサービスを始めるのは簡単なイメージを持っていた。一方で使い続けるには難しいというイメージを持っていた。
  • 立ち上げ時はモノリシックなRailsアプリ構成
    • ビジネスが拡大しても同じデータを読み込んでモデルのロジックも共有したいという思いからモノリシックな構成に。
  • サービス拡大期(3年目ぐらいから)はサービスを多産多死
  • サービスを追加する際、インフラを構築する時間が長かった(1週間)ので、モノリシックな構成を続けていた
  • モノリシックな構成が限界を迎え始めた
    • 直接関係ない機能の障害によるダウンタイムの発生
    • Railsの起動時間が長い、メモリ消費量の増大など
  • インフラ初期構築は1回やればおしまいということから、モノリシックな構成からの脱却を行った。
  • 現在はMicroservice化
  • やりたいことがRubyでできないことが多い
    • 画像解析ではC++とか
    • 他にもgolangとかやりたいことに応じて技術の適材適所を行っている

木村 圭宏氏による『プログラミングスクール卒業生による受託開発サービス立ち上げとその課題』

  • プログラミングスクール(Dive into Code)卒業生による受託開発サービスを立ち上げて1年経った。そのときに発生した課題について
  • 発生した課題は
    • 案件がない
      • 請負ではなく完全時給型でやったので、実績がない我々に対しては中々案件が来ない
    • 実務経験者0
      • 見積り基準が欠如
    • 人が居なくなる
      • 中心人物に作業が集中してしまう
    • 状況が不透明
      • 基本はリモート作業
      • コミュニケーションが希薄になりがち
    • 教育コストが高い
      • 開発ツールの使用方法などの教育コストが案外高い
      • コードレビューでの指摘も自然と多くなる
  • 問題点を一言で言うと「開発=プログラミング」ではない。開発には設計やインフラ、各種調整など様々なものが含まれている。
  • 上記の課題を解決するために色々と取り組んでいる。幾つかを紹介。
    • 分報
      • 日報の更に細かいもの。Slack上に自分用のつぶやきチャンネルを作成して、色々と呟いてもらう
      • コミュニケーションのハードルが下がった
    • チーム開発演習
      • プログラミングスクール卒業後にチーム開発演習を取り入れる

感想

村田 賢太氏による『Rubyにおける機械学習のための環境整備の取り組み』が一番興味ひかれる話でした。丁寧に各種用語の説明があった後にデータサイエンスの領域における現在のRubyの立ち位置の解説とその解決について述べ、最後にデモも付いていたので、終始引き込まれました。

ビジネスという分野だとやはりRailsの話が中心になるのですが、そろそろ「Railsで早期にサービスをリリースすることができてHappy」という話からWantendlyさんのように長期間サービスを動かしてきたときの話が中心になるのかなと思っています。

そういうときに問題となることの一つがRuby技術力の維持と向上と考えています。そのため、伊藤 浩一氏によるLT『Railsアプリケーションプロジェクトでの読み書きそろばんの1周目、2周目とそれから』や森 雅智氏による『TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り』は勉強になりました。