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

第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

次回は?

次回は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

はじめに

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

感想

衝撃的だったのは、「テストを書く文化の醸成には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化か新システムに移行かの二択ですが、また、いろいろと考えてみようかなと思います。

最後に言い訳

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

RubyKaigi 2015のStaffとしてRubyKaigiの運営お手伝いをした

はじめに

2015年12月11日(金)〜13日(日)で開催されたRubyKaigi 2015。そこでRubyKaigi 2015のStaffとして参加しました。ここでは、Staff目線で今回のRubyKaigi 2015を振り返りたいと思います。

f:id:miyohide:20151215001352j:plain

きっかけ

そもそもRubyKaigi 2015のStaffになるきっかけは6月某日にオーガナイザーから来た1通のMessengerでした。Messengerには

「ぼくといっしょにRubyKaigiをつくりませんか」

と記されておりそこから今回の話がスタートしました。大変なことになるだろうなとは思いましたが、オーガナイザーの熱い思いに感化され、10分ぐらいで「はい。よろしくお願いします。」とお応えしました。

準備

地域Ruby会議をStaffとして参加したことはありますが、RubyKaigiのような大規模カンファレンスでのStaff経験は初めてです。地域Ruby会議とは

  • 入場者数
  • スポンサー
  • 用意するノベルティや設備

などの面において桁が変わってきます。普段のn倍だから...とのんきに構えられる量ではなく、いろいろと考えることが増えました。

具体的には、入場者がスムーズに動くことができるためにはどのように会場をレイアウトすれば良いか、ノベルティは何日前に発注*1し、いつまでに入金しなければいけないか*2、送付される荷物の量は会場のキャパに収まるかなどなどを考えてデザイナーさんや振込担当者さん、業者との調整をするのは今回初めての経験で、色々と勉強になりました。

チーム間のコミュニケーションにはidobataesa.ioを使いました。idobataは簡単なチャットとして、esa.ioは議論の叩き台やまとめを書く場所としてそれぞれ活用しました。ちなみに、esa.ioといえば、このるびまの記事を読むといいと思います。

文字ベースのやりとりだけでなく、ミーティングを重ね、徐々にオーガナイザーや他のStaffと言葉をかわしていきました。Staffはそれぞれ別の会社に勤めているので、いわゆるオフラインミーティングを取るのは二週間に一度ぐらいが限度だったのですが、オンラインミーティングを随時に入れ込むことでカバーしました。文字ベースだけのやり取りは誤解を招いたり、真意が伝わりづらいことがあるので、こういうやり取りは良かったかと思います。
オンラインミーティングとして使用したツールとしてはhangoutsやSkypeが多かったです。これらのサービスは回線速度があまり出ない時でも安定してコミュニケーションを取ることができました。

自分の中では、当日発注したノベルティや準備品などの荷物がちゃんと届いているかは不安だったのですが、当日、会場に入った時にパーカー・Tシャツ・ストラップ・名札・各種機材等々が全部届いているのを見た時、心のなかでガッツポーズしました。

当日

私に割り当てられたタスクは会期運営。会期中起こることをいい感じにハンドリングして、いい感じに解決するというお仕事を担当しました。

具体的にはHall Aにてタイムキーピング、各種アナウンスを受け持っていたのですが、その他にアナウンス・スライド内容の作成と調整、撤収作業に向けた各種手続き、ゴミの回収と片付けを実施していました。

また配布品の一つとして、スケジュール表がありました。これはオーガナイザーの方による提案で作成に至ったのですが、これが我々Staffの中でも大活躍。自分はここにいろいろと書き込みをして、アナウンス内容等を忘れないようにしました。

そんなこんなでドタバタしぱなっし。うまく行ったとかドジッたとかそういう実感を感じる間もなく3日間が終わってしまい、とりあえず乗り切った感が強いです。

終わりに

なんだかんだあっという間に過ぎ去った3日間でした。会場の片付けが終わり、自宅に帰ったらただただ泥のように眠ってました。会期中はあまりセッションの内容が聞けなかったので、スライドや後日公開される動画でゆっくり復習しようかと考えています。

あ、来年は京都のようですね。会期期間中、「来年は5K FUN RUNをやってみたら?」と言われたので、ちょっと音頭とってやってみようかなと思ったり思わなかったり。真夏の京都ということでかなりつらそうですが(^^ゞ

*1:だいたい10営業日前がデッドライン

*2:基本は前金。受け取り日付と業者の稼働日に合わせて振込する必要あり

「Crafting Rails 4 Applications」をオンライン読書会で読み終わりました

はじめに

「Crafting Rails 4 Applications」という本を、先日読み終わりました。

f:id:miyohide:20151103212416j:plain

今回、この本を読み終わるために、オンライン読書会という手法を使わせていただきました。このエントリーでは、読み終わるためにやったことを記します。

本の紹介

「Crafting Rails 4 Applications」は便利なツールを作ることを通してRuby on Railsの内部構造を解説していくという1冊です。The Pragmatic Bookshelfにて発売されており、DRMフリーなPDFが購入できます。

pragprog.com

Ruby on Railsを勉強しはじめ、RailsTutorialを一通りこなした人が読むと良い本と紹介され、読んでみることに。洋書ということもあり、英語の面が気になりましたが、

  • サンプルとして公開されている部分を読むと、辞書片手に読めなくはないと思った
  • ソースコードとテストコードがそれぞれ丁寧に書かれているので、最低でも何かモノが作れる

という思いがあり、読み進めることにしました。

挫折しないために

それでも洋書は読み続けることは難しいです。和書でさえ積読にすることが多いのに、洋書を読み進めることができるんだろうかと不安になっていました。

ちょうどその頃、 @tatsuoSakuraiさんが「オンライン読書会で読み進めませんか?」というお誘いをいただき、それに乗っかってみることにしました。

オンライン読書会とは

我々がやったオンライン読書会は、月に2回それぞれ1時間の枠でWebチャットのLingrに集まり、本を読み進めるというものでした。

当初は本文を1文1文訳していましたが、さすがにそれだと進みが悪かったです。そこで、参加メンバーが固定化された時からは、ある程度予習していることを前提に、「ここはこういうことを書いていますよね?」という形で段落単位でざっくり読み進める形にしました。

また、ソースコードが出てきた時には写経をしました。写経には5分や10分程度の時間を取り、実際にソースコードを入力し、実行します。

写経は、本に書いているソースコードを自分で入力するということだけですが、実際にテストを動かしてみると失敗したり、異常終了したり。本に書いていないことが次々と起こります。理由はいろいろありますが、

  • 単なるタイポ
  • 本が書かれた時とはフレームワークやライブラリがバージョンアップし、仕様が変わった

が主な原因だったように思います。後者は特に原因追求が難しいので、最初は本に書かれているバージョンで写経すると良いかなと思います。 ただ、それだけでも写経は意味があるものと思っています。特に本に書いていない挙動を起こすと必然的に本を必死で読み返し、ソースコードの意味を理解しようとするので、写経の際にわざと間違えてみるというのも良い勉強方法では?と思ったりします。

予習

オンライン読書会の進め方が変わったことも有って、予習をちゃんとするようにしました。 自分がやったのは、読書会の前になると定期的に該当ページを印刷し、わからない単語は辞書で調べ、意味が通る日本語訳にするようにしておきました。こういうときにDRMフリーのPDFが買えるのはいいですね。

もちろん、全部きれいな日本語訳にできたわけではないですが、わからないところと印をつけておいて、読書会で聞くようにしました。

それにしても長かった

第1回の読書会が2013年8月19日、終了したのが2015年11月2日でしたので、かれこれ2年以上やりました。流石にひと月に2回、1回1時間という枠だと短い感じがします。オンラインという特性を活かして、もう少し頻繁にやっても良かったのかもしれません。

謝辞

それでも、2年以上続けられたのはオンライン読書会に参加してくれた人が居たからです。企画者である@tatsuoSakuraiさんやRuby on Railsの最新動向に詳しい@y_yagiさん、英語訳について適切な指摘をくれた@netwillnetさんには助けられました。ありがとうございました。