大阪マラソン2016を走ってきた

2016年10月30日（日）に開催された大阪マラソン2016を走ってきました。

f:id:miyohide:20161030145154j:plain

幸運なことに抽選に当たったので、参加することに。

connect.garmin.com

目標はサブ4。キロ5分半で30キロまでは走り、そこからは残った体力勝負ってな感じで入ったのですが、残り5キロぐらいから大体死んでました。

最後、気力を振り絞ったのですが、サブ4まであと一歩足りず...というか、わざわざ手に入れているものを自ら放棄している感じかも。

f:id:miyohide:20161030154148j:plain

前日

ゼッケン受付が前々日と前日のみ。事前配送物はなく、ネットで手続きをするだけ...なんだけど特に通知も何もなく、たまたま覗いたWebページでネットでの手続きが必要なことに気がつきました。ちょっと不親切な気がします。

前日の土曜日に横浜から大阪に移動し、ゼッケンを受け取ったあとは早々にホテルに向かい、早々に就寝...しようとしたのですが、ちょうど日本シリーズをやっていたので、寝るに寝られず。結局23時ぐらいまで起きてしまいました。

当日（スタート前）

朝は5時ぐらいには起きて朝食。準備をして6時半にはチェックアウトして大阪城公園へ。すでに多くのランナーで電車が埋まりました。

荷物預け締切が8時。整列締切は8時40分。荷物預けはサクッとできたのですが、整列はトイレ渋滞と整列場所までの混雑がひどく、30分前に移動開始したのにギリギリセーフ。ここらは運営側の改善がほしいところ。

スタート

あたふたしたままスタート。スタート直後の渋滞もそんなに無く、キロ5分半のペースを掴む。このままいけるかなぁと思ったけど、どうしてもペースが上がってしまう。抑えよう抑えようとずっと心がけながら走る。

10キロあたり

5分半/kmを目安に走っていると、いきなり肩を叩かれる。何事？と思っていたらランステで見知った仲間が。ちょっと元気が出る。このままペースを維持しながら距離を刻む。

20キロ過ぎ

半分。ちょっと疲れている。いつの間にかランステの仲間とも離れ、途中で「サブ4目指している」という桧山のユニフォームを着たランナーと並走する。大阪という土地柄なのか、阪神のユニフォームを着た人を結構見かける。

30キロ過ぎ

時計を見るとちょうどいいペースで来ている。これからが辛いところ。体の調子がダイレクトに出てくる。

そんなさなか、右ふくらはぎがちょっと痛みだす。これまでになかった痛み。ちょっとやばさを感じる。

37キロ過ぎ

南海大橋あたりで右ふくらはぎが攣りそうになる。やばい...。ちょっと歩いて様子を見る。大丈夫そうなので、徐々に走ると痛みが出てくるポイントがあるのでほぼ早歩きな感じで前に進む。後5キロ。こんなに長かったっけ...

ゴール

そのまま痛みはあまり引かずにゴール。う〜ん、ちょっと悔いが残るタイムだしレースであった。ちょっと残念。

ゴール後

ゴール後は、ゆっくりと着替えをし、無料のマッサージを受ける。会場から大阪駅までの直行バスを予約していたのでそれに乗って帰る。このバスは完全予約制。自分は17時の便を予約していたんだけど、早めに行って聞いてみたら「空席があったらOKですよ」ということ。無事、空席が出て早めに帰ることに成功。その後はJRで新大阪まで行き、新幹線で横浜まで帰る。マッサージを受けた結果か、そこそこ普通に歩けて帰れた。

反省会

やっぱりというかいつも通りというか、35キロ過ぎが自分にとって勝負。辛い時にかんたんに心が折れてしまうのはどうやって鍛えたらいいんだろうと思うんだけど、やっぱり長い距離の練習なのかなぁ。

RubyWorld Conference 2016で喋ってきた

はじめに

2016年11月3日と4日に島根県松江市で開催されたRubyWorld Conference 2016で講演者として参加してきました。

RubyWorld Conferenceは、毎年島根県松江市で開催されるRubyのカンファレンスなのですが、出席者の半数ぐらいがスーツな人で占められる不思議なカンファレンスです。県知事と市長による挨拶があるカンファレンスはおそらくこれぐらいでしょう。

f:id:miyohide:20161106205017j:plain

CFP

講演者としてRubyWorld Conferenceに行くためにはCFPを出して採択される必要があります。ここ数年の傾向を見ると、

  • システムをRailsで構築しましたっていうのはすでに当たり前なので、採択される可能性は低い
  • 去年ぐらいからmruby関係の採択率が高いような気がする
  • 教育は一定の枠がある感じ
  • 深い技術的な話はあまり求められていないようなきがする

みたいな感じ。今回は、参加しているOSS推進フォーラムアプリケーション部会でやっているmrubyの話をまとめてCFPとして出したら採択されました。

発表内容

半数以上がスーツな人で占められることと、mrubyに関してはET展などで「どうやって始めていいかわからない」っていう声を多く聞いたことから、mrubyでアプリケーションをどうやって作るかについて簡単に紹介することに時間を費やしました。

後で話を聞くと「分かりやすかったです」という声をたくさん聞いたので、狙いとしては成功だったように思います。

時間の関係上、

  • mrbgemsの探し方（詳細版）
  • mruby-cliについて
  • Azure Web AppsでRailsアプリを動かす方法

については全く喋りませんでしたので、聞きたい人がいましたらお声がけください。

あと、資料は後ほどRubyWorld Conferenceの公式サイトにて公開される予定です。

テーマについて

今回は、mrubyを使ってセンサーデータを収集してAzureにデータを送信するって話をしたのですが、最初始めるときは色々と舐めてました。

  • mrubyってほとんどCRubyと同じでしょ。同じアプリをちょっと編集すれば動くでしょ。
    • →う、動かない...
  • mrbgemsってググれば適当に見つかるでしょ。
    • →見つかることは見つかるんだけど、どう書けばいいか分からない
  • Raspberry Piでとりあえず動かしてみて、すぐさま組み込みにチャレンジだ
    • →組み込み、めっちゃ大変。半田付け難しい、メモリ足りない

実際にやってみるとその大変さが分かりました。

今回は、「CRubyでいいじゃん」ってな結果になったのですが、徐々にmrubyでしか出来ないようなものにもっていきたいので、徐々に突き止めてみようかなと思っています。

第70回 Yokohama.rb にてどう書くの問題にチャレンジした

はじめに

毎月第二土曜日ぐらいにYokohama.rbという地域Rubyコミュニティを開催しています。ここ最近、レシピブック読書会を @igrep さんと @nabetani さんに丸投げしていていました。

Rubyレシピブック 第3版 303の技

Rubyレシピブック 第3版 303の技

このままの状況、運営としてはイケてない！と感じ新しいコンテンツを探そうと思っていたところ、 @nabetani さんから「どう書く」のYokohama.rb版を提供して頂けることになり、早速試してみました。結局人様に頼りっきりで申し訳ないんですが...


今回の問題

今回の問題は、Rails on Tiles yokohama.rb 2016.7.9 問題。

自分の戦略

ポイントは、画像で表現されているタイルをどのようにプログラムとして表現するか。ここがいろいろと悩みましたが、自分は「上辺のものはどこに移動するか」「左辺のものはどこに移動するか」...という形でHashで表現しました。こんな感じ。

Tiles = [
  {top: :left, left: :top, right: :down, down: :right},
  {top: :right, left: :down, right: :top, down: :left},
  {top: :down, left: :right, right: :left, down: :top},
  {top: :death, left: :death, right: :death, down: :death}
]

あとは、入力文字列をParseしてフィールドを作り、枠外もしくは行き先がdeathに行ったら処理終了という流れでベタに書きました。それが次のコード。


Yokohama.rb 70回で出題された問題の回答です。

わかりやすいコードを書くことを心掛けているので、多少長いのはしょうがないのですが、流石に長過ぎるのでもうちょっとあがいてみます。

他の人の答え

  • @hamaknさん


70th Yokohama.rb どう書く http://nabetani.sakura.ne.jp ...

  • @nabetaniさん

qiita.com

  • @nomnelさん

nomnel.hatenablog.com

Togetter

togetter.com

次回は？

次回は8月第1週の8月6日開催予定です。

yokohamarb.doorkeeper.jp

TokyuRuby会議10でLTしてきた

概要

TokyuRuby会議10でLTしてきました。

ネタは、次のるびまシステムについて。

Markdownで書きたいというニーズは結構あるのですが、そこが本質ではなく、運用に疲れ始めたからというのが今回のLTのネタ元です。

進捗

で、肝心のシステム刷新ですが、手元では全記事の移行ができています。が、表示させてみるとレイアウトが崩れたり、Amazonの書影を取ってくるところが未実装だったりするのでなかなかリリースまでは程遠いかなと思っています。

TokyuRuby会議という場

TokyuRuby会議の一部の回はサントリーさんがスポンサーになっているということで、大量にビールが出てくるということで有名です。また、各人が自慢の料理を持ち込んできて「飯王」を決めるということもあって、料理に夢中な人もたくさん。後半ぐらいになると半分ぐらいの人は発表を聞いていないとのこと。たしかに自分の場合もそうでした。

そんな中、まじめな発表をするのはちょっと怖かったのですが、終わってみれば、多くの人に聞いていただき発表に対するご意見もたくさんいただきました。発表やってよかったと実感しました。

発表という機会

今回、発表するということで、できるだけ進捗を出したいと思い、どんどん開発が進みました。発表資料を作りながらの開発は大変でしたが、締め切りができるとそれがモチベーションになって開発が進むので、大変有意義だったです。また、機会があれば発表したいなと感じた一日でした。

最後に

当日は体調不良で発表直前まで休憩室で横になってました。いろんな人にご心配・ご迷惑をお掛けしました。ごめんなさい。

「Patterns of Enterprise Application Architecture」を読み終わった

「Patterns of Enterprise Application Architecture」を読み終わりました。

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

自分が読んだのは洋書版。途中から日本語版も合わせて。500ページ以上の洋書を読むのに1年2ヶ月かかりましたが、ようやく読み終わりました。ざっと感想を。

  • ソフトウェアを書く人にとって「これ読んでないとモグリでしょ」感がある一冊。たしかに読んでいて、「あ、この言葉よく聞くわ」とか「このパターンあるある」って言うことが多かったです。
  • （この本の）英語難しい。文の途中でいきなり例が出てきたり、辞書にない単語が沢山出てきたり、なかなか苦労。
  • というわけで、読んでいて流石に意味が取れないのはまずいと思って日本語訳版を購入。購入時は電子書籍版が出てなくて、書籍版も出ていない状況だったので古本で。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

  • 500ページ以上あるということで心折れそうだったんですが、1日2ページぐらいのペースで徐々に読み進めていくと、意外となんとかなった。
  • ベストプラクティスでもないし、サンプルコード（JavaもしくはC#）がそのまま打てば動くようなものでもないです。というわけなので、「明日使えるコーディング例がここに」って感じではないです。
  • 1回読んですべてを理解しようとしてはいけない気がします。一回目はさらっと全体を通して読んで、2回目3回目ぐらいでそれぞれのPatternの相互関係を読んでいくスタイルが良いかなと。となると、あと2回は読まないといけないのか。むぅ。
  • 古い本なので、サンプルとして出ている内容がJ2EEとかEJBとか。時代背景を知っていると楽しく読めるような気がします。
  • とはいえ、著者の先見性が所々に垣間見えたりするし、そんなに技術的な流行に流される内容ばかりではないです。コーディング技術よりも一歩下のレイヤーの部分が書かれています。その分、分かりにくいところはあるんだけれども、繰り返し読んでいけば分かってくる気がする（自分もそうありたい）。
  • 紙に出力して単語を調べて文の区切りに斜線入れて読むのが自分には有っている洋書の読書スタイル。これ、iPad Pro + Apple Pencil だとちょっと変わるのかな？

f:id:miyohide:20160421234511j:plain

というわけで、きちんと理解しているとは言いがたい「Patterns of Enterprise Application Architecture」。ちょっと間を空けて、また再読したい。

『組織にテストを書く文化を根付かせる戦略と戦術』を聞いて #jopf

はじめに

先日開催された『開発を活性化するためのポイントとテストに関する勉強会』にて、『組織にテストを書く文化を根付かせる戦略と戦術』のお話を聞いてきたので、そこでの内容と自分が所属している組織への適用について記してみます。

各種資料

発表資料

Togetter

togetter.com

感想

衝撃的だったのは、「テストを書く文化の醸成には2年ぐらいかかる」という言葉。

一日二日でできるとは思っていないんですが、まさか年単位とは。

そのため、勢いで乗りきれるほど甘くはなく、戦略と戦術でもってテストを書く文化を醸成しましょうという話に続きます。

スライド10ページ目で引用されている『テストを書く時間がないのではなく、テストを書かないから時間がなくなるのだ』

でさらっと、テストを書かない理由No.1に対する厳しい答えを提示し、戦術として「どこから手を付けるか」（スライド21ページ目）や、「テストでこだわりがちなところに対する警鐘」（スライド24ページ目）、「テストでのこだわりポイント」（スライド25ページ目）を例示されて、一つ一つが勉強になりました。

で、どうする

一番手っ取り早いのは、自分のテストスキルを上げることかなと思います。発表の中でも言われていましたが、「レガシードコード改善ガイド」を読んで用語や考え方を身につけ、

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

実際にテストを書いてみるというのを自分はやっています。

Ruby/Railsでは、『Read Everyday Rails - RSpecによるRailsテスト入門 | Leanpub』や『Rails 4 Test Prescriptions』などがよいように思います。

pragprog.com

後は、公開されているOSSには結構テストが書かれていないことが多いので、テストを追加するPull Requestを出すというのもいい勉強になるかなと思っています。

実際に組織に展開するというフェーズについては、それぞれ組織ごと・チームごとに異なるように思えます。私が言われたものでも、

  • テストを書く時間がない
  • テストを書くためのスキルがない
  • テストコードの品質が担保できない
  • それは（QA｜開発者）の仕事
  • テストコードによって生産性が上がるといった定量的指標がない

などなど。あー言えばこー言う状態なので、真正面でぶつかってはダメで、地道に答えを用意するのが一番早いように思っています。

それか、トップを仲間につけてトップダウン式で強制させるというのもある組織形態では有効な気がします。

冒頭で書いた「文化の醸成は年単位の事業になる」という言葉を旨に、いろいろと試行錯誤するしか無いのかなと思っています。

某Webマガジンのベースシステム移行計画（案だけ）

きっかけ

先日、Yokohama.rbにて某Webマガジンに最近コミットしている人たちが複数人集まったので、その話が盛り上がりました。実現するかどうかは分かりませんが、ちょっとメモっておきます。

もともとの要望

もともとは、「markdownで記事を書きたい」という要望です。Webで表示するコンテンツを書く上で、特にエンジニア界隈ではmarkdownは標準的な知識として定着したように思えます。そのため、独自文法よりもmarkdownで書きたいというのは自然な要望かと思います。

潜在的な要望

ただ「新しい文法で記事を書きたい」というのは理由としては表面的なもので、潜在的な要望としては次のものがあることが分かりました。

  • 現在の文法では表現できていないものがあるので、それを解消したい
  • 著者自身がローカルでレイアウトなどを確認しながら記事を作成したい
  • その他もろもろ

新しいシステムは何がよいか

こういう要望が高いことが分かったので、「markdownで記事が書けるシステムは何が良いか」というのをちょっと探してみました。探してみたのは、いわゆる静的サイトジェネレーター。Ruby製で言えば、

ぐらいでしょうか。また、コンテンツマネジメントシステム（CMS）もおそらく調査対象になるかなと思います。まだ調べ始めた感じなので、それぞれ使い勝手をいろいろと見ながら方向性を決めていきたいなと思っています。

ざっと必要な機能を洗い出してみると、

  • markdownで記事が書けること
  • ソースコードのシンタックスハイライト機能があること
  • 画像を貼り付けることができること
  • ユーザ認証機能があること
  • アクセス制御機能があること
    • 特定の日まではユーザ認証を受けた人だけしか参照できない
  • 目次作成機能
  • 類似記事リスト化機能

ぐらいなので、後は触ってみた感じで適当に選んでみることでしょうか。

なお、「自作する」というのは除外しています。そもそもスタッフが少ない中、できるだけ手間を掛けたくないという思いがあります。そのため、どうしてもメンテナンスが高くなる自作についてはちょっと除外したいなと考えています。

運用フロー

システムと同様に、運用フローについても考えないといけません。できれば、pull requestを出すことで回していきたいという思いがあるのですが、随時に記事をリリースする形ではなく、定期刊行という形を取っている以上、ちょっと難しいかなと思っています。

また、費用面の問題もあり、できるだけ低コストで済ませたいという思いがあります。

移行

実は、一番頭を悩ませているのがこの移行です。すでに少なくない記事をリリースしていることもあり、移行するとなるとちょっと頭を悩ませる問題です。

移行と言っても様々な方式があり、ざっくり

  • ばっさり切り捨てる（全部なかったことにする）
  • 静的HTMLとしてどっかにホストしておき、新システムとは別のものとする
  • 新システム用に全部移行する

という案が挙げられます。バッサリ切り捨てるというのは多分ありえないので、静的HTML化か新システムに移行かの二択ですが、また、いろいろと考えてみようかなと思います。

最後に言い訳

ということを考えたり考えなかったりしていたら、いつの間にか年末になったので、この冬休みの間にでもちょっと調査してみようかなと思い、エントリ化してみました。が、実現できるかどうかはまた別の話です。