最近、よく本を読むようになりした。これは千葉に引っ越して通勤時間が長くなったことにも起因しているのですが、
他にも理由があります。
私は通勤の電車の中では大体ノートPCを開いてコードを書いたり文章を書いたりしています。
総武線は千葉駅始発で大抵の場合は座っていけるのですが、鈍行では時間が掛るので急いでいるときには快速電車に乗ります。
快速電車はそれなりに混みますので座れなかったりします。
そういう場合はiPhoneでパズルゲームなどをしながら時間を潰します。
こういう時には本を読むとよいと思うのですが、物理本を持って歩くには思いしiPadでも同様です。
iPhoneでは画面がせまくて字も細かくなるので本を読むには向いていません。
kindle端末も考えるのですが、老眼が進んできた眼が疲れやすい私にはkindle端末でも字が細かすぎるかもと躊躇してしまいます。
眼が衰えてきていよいよ老眼鏡リーディンググラスが必要になってきたので試しに100均でリーディンググラスを買ってみたら、iPhoneの画面で細かい文字までよく見れるようになりました。
もともと、眼が衰える前でもiPhoneの狭い画面で本を読むなんて考えられなかったのですが、いまでは電車の中でiPhoneで本を読むようになったという訳です。
眼が衰えていない人でもこの読書体験は良いかもしれません。お勧めです。
そういうわけで最近読んでいる本は次の2冊。
いんようで度々話題になる横浜駅が増殖するという荒唐無稽な世界を描くSF小説。
こちらは仕事向けの本。pmconf2019でその存在を知った本。(いやユビレジの本棚にもあったような…)
序文だけでも読む価値あり。
おひさしぶりです。
年を明けてからずっと続けてこられたブログですが、ついに途切れてしまいました。
毎日書かなくてはという枷はこういうときに、もういいやっていう気持ちになってしまいそうなので、必ずしも毎日じゃなくてもよいというルールで運用していこうかと思います。
さて、表題の通りの質問がQuoraにあったので、思うところを書きました。
Quoraも始めたときには一生懸命書いていたのですが、最近は放置しています。
ブログがんばることを決めたので、ブログのネタがないときにはQuoraの質問に答えたりするのもよいかなと思いました。
さて、表題の質問です。
https://jp.quora.com/IT-enjinia-toshite-shigoto-shi-te-masu-hoshu-unyou-yori-shinki-kaihatsu-ga-shita-i-desu-shikashi-ki-zu-i-tara-hoshu-unyou-no-shigoto-ga-ooku-nari-masu-donna-riyuu-ga-kangae-ra-re-masu-ka/answers/192764085
質問者の方は新規開発をしたいのに保守運用の仕事ばかりになるという質問なのですが、イマドキのソフトウェア開発では常に新しい価値を出していかなければ勝ち抜いていくことはできません。保守運用ばかりではいずれビジネス行き詰まってしまうのではないかと心配してしまいます。
もっとも、保守運用でお金を稼げているのならそれはそれで幸せなことかもしれませんよね。
今日はRubyKaigi2020のCFPを書いたり、そのための調査をしていたりしました。
CFPの締め切りは明日ですが皆さんもう出しましたか？
CFPをどんなふうに書いたら採択されるかは多くの人がインターネットに書いています。いくつか紹介しますね。
RubyKaigiでどういうトークが採択されやすいかという話を以前、unasukefmで松田さんが話していたのですがこの話は今は聴けなくなっていますね。
どういう話だったかというと、少なくとも松田さんが聞きたいトークというのは自慢大会だということです。こんなソフトウェアをRubyを使って作りましたとか、Rubyでこんなことやってるとかですね。
上のはすみさんの話はまさにそれでmruby/cで酒造の温度管理するとかちょっとイカれていて(誉め言葉)ここでしか聞けないという話になっています。
私も大体自分でつくったgemの自慢をしに行くような感じです。
それとRubyの処理系自体の話も多いですね。これもRubyKaigiならではという感じ。
こっちは話せる人が限られる感じですが、自慢大会のほうは自慢できるものがあればみなさんどんどん応募したらよいかと思います。
CFPに応募してスピーカーとして参加するも良いですし、惜しくも採択されなかった場合でもCFPを出した人はアーリーバードのお値段でチケットを買うことができるそうなのでぜひ応募していきたいところです。
CFPに出していない人も是非松本で会いましょうね。
なんとあっさり見つかりました。きっかけは今日「iPhoneを探す」で1/9 0:12に中野駅にあることが示されていたことからはじまります。
ちょうど都内に出ていたので中野駅まで確認しに行ったところ、それらしいものがあるということでした。ただし、すでに東京駅の遺失物センターに移動してしまっていて明日には警察に届けるとのこと。
その足で東京駅の遺失物センターに行くとあっさりみつかりました。
そして、中野駅に届けられたのは当日(1/7)の11時頃ということだったので拾ってくれたひとはすぐに届けてくれていたということのようです。(疑ってごめんなさい)
しかし不思議なことがいくつかあります。
- 最初に「iPhoneを探す」で探したときにはオフラインだったこと。
- JRの遺失物センターには何度か問合せをしたがみつからなかったこと。
- 「iPhoneを探す」で銀座でオンラインになったという通知があったこと。
- 銀座でオンラインになったの通知の前に中野駅にあることが判っていたこと。
以上のことを鑑みると「iPhoneを探す」があまり当てにならないことがわかります。
(ただし、今日みつけることが出来たのは「iPhoneを探す」のおかげだったので全く当てにならないというわけではありません。)
そもそもiPhoneがどのようにしてオンラインになったのかが不明です。「iPhoneを探す」でオフラインだとわかったタイミングでモバイル通信は無効化しています。(多少タイムラグはありますが)
なので、銀座でオンラインになったという通知が来たときにはどのようにしてネットに繋ったのでしょう？しかもその時には中野駅にあったのです。謎は深まるばかりです。
そして、JRの遺失物センターも届けられてすぐには検索可能な状態にはならないということがわかります。
これは当然といえば当然です。駅に遺失物として届けられたとしてもシステムに登録されるまでにはラグが発生します。
忙しい駅員さんが遺失物のシステムへの登録を先延しにしてしまうことはありえるシナリオでした。
もっとしつこく問い合わせをしていればよかったなというのは後の祭です。
という訳で今回の教訓は
- 「iPhoneを探す」の情報は鵜呑みにせずにオフラインになっていてもあきらめてはいけない
- 鉄道などの遺失物センターにはすぐに登録されるということは期待せずに何度も問合せせよ
ということになります。
なにはともあれ、見つかってよかったです。すでに新しいiPhoneは買ってしまったので元のiPhoneは売ることにします。
もし、このブログを読んでいる方でほしい方は連絡をください。
mercariで6～7万円くらいで取引きされているようなので、知り合いであれば6万円で譲りたいと思います。
箱なども残っています。
2020年はじまって早々にiPhoneを失くしてしまいました。
私は通勤時間が長いので電車の中でよくコードを書いたり、ブログを書いたりしています。
ひざの上にラップトップを置いて、iPhoneのテザリングをつかってネットに接続しています。
iPhoneの操作をしてそのままひざの上(ラップトップの下)に置いてそのまま作業してしまうこともあります。
その日もそんな感じで作業をしていて、電車を降りて階段を降りようとしたときにiPhoneが手元にないことに気がつきました。
わたしはスマートウォッチのMuse wearablesを使っているのでiPhoneから離れるとすぐに通知で気付きます。
しかし、気付いたときには電車が発車したあとでした。
駅の事務所に行ってその旨を伝えると、その電車は中野ゆきの電車(降りた駅は新宿です)ですぐ車庫に入る電車なので中野で探しますとのことでした。
ところが中野では見つからず、しかたがないので会社に出社してからiCloudのiPhoneを探すで調べたところわたしのiPhoneはすでにオフラインになっていました。
ちょっと不思議です。iPhoneは当然モバイル通信ができるため圏内であれば常にオンラインのはずです。家を出るときには満充電だったので電池切れの可能性も低いです。
そうです。わたしのiPhoneは電源を切られて持ち逃げされたのです。この行為は遺失物等横領罪(あるいは占有離脱物横領罪)という刑法上の罪になります。他人のスマートフォンなどを拾った場合は鉄道であれば駅事務所、建物内であれば建物の管理事務所など、その他の場所であれば交番・警察署など適切な所に届けましょうね。
さて、そんな訳でiPhoneが横領されたわけですね。わたしはすぐに「iPhoneを探す」で紛失モードにして電源が入ったときに連絡先(携帯電話の番号はその時点では使えない状態なので会社の電話番号にしました)が表示されるようにしました。
ここで疑問なのはiPhoneを持って行った人はそれをどうするのか？ということです。iPhoneはアクティベーションの解除は本人(あるいはパスコードを知っていてロックを解除できる人)にしか出来ないようになっています。一時期iPhoneの盗難が問題になっていてかなり厳重になっていて素人にはそれを破るまず無理でしょう。
SIMは抜いて別の端末で使うことも出来るのでSIMはすぐに回線事業会社に連絡して止めてもらいました。
あとは警察に連絡するだけなのですが、電話で遺失物センターに連絡するも電話がつながらずでまだ届け出が出来ていない状態です。
携帯電話がないのも不便なので新しいiPhoneを買って、SIMを再発行してもらいあきらめるしかないかなと思っていたところ「iPhoneを探す」からiPhoneがオンラインになったという通知がemailで来ました！
場所はなんと銀座です。
一応見に行ったのですが、その辺りに落ちているわけもなく建物の中にあるなら見つかるわけもなくという感じで写真だけ撮って帰ってきました。
ちなみにこの場所はわたしは見覚えのある場所で、以前にmacbookに水をこぼして壊してしまったときにSSDの中身を復旧できないかとデジタルデータソリューション株式会社というところに依頼したことがあるのですが、そのオフィスがすぐそば(GPSの誤差の範囲内くらいの距離)にあります。
まさかと思いますが業者にロック解除を依頼したのでしょうか。盗難品だと分かれば業者では対応しないでしょう(紛失モードになっているので分かるはずです)。1/10の19:00ころにオンラインになって、「iPhoneを探す」では1/11の12:12まで追跡できています。その後は電池が切れたのでしょうか、またオフラインになっています。
とりあえず警察に届けて状況を静観しようかと思います。また何か事態に変化があったらここに書こうと思います。
今日は技術的な内容ではありません。
映画「プロメア」が上映中に観られなかったのですが、阿佐ヶ谷ユジクというミニシアターで上映しているという情報を得て観てきました。
映画のレビューとかあまり書ける気はしないのですが感想をすこし。
「天元突破グレンラガン」や「キルラキル」を観てきた人にはおなじみのTrigger作品です。もうこれでもかってくらいにTriggerだったのでそれだけで満足でした。
至る所でグレンラガンやキルラキルのパロディーも出てきたので、予習してあるとより楽しめると思います。
いんよう！でも言っていました。
Trigger作品といえば、後半になるにつれてこれでもかこれでもかというくらいに何度もカタルシスを向かえてどんどん盛り上っていく展開が持ち味ですが、
この作品は2時間程度の映画作品であるというのもあるけど、そのあたりがちょっと抑え目だったように思います。(2時間の中にあれだけ詰め込んでいれば充分という話もあります。)
序盤のお遊びの部分も面白かったです。全体的に完全にTriggerっぽいのですがちょっと新機軸を入れていくという感じでバランスの良さを感じました。
Triggerファンには絶対おすすめなのですが、そんな人は当然すでに観ているだろうと思うので、Trigger入門の人はグレンラガンを観てから観るか、プロメアを観たあとにグレンラガンを観るのをお勧めします。
https://omotesandorb.connpass.com/event/161445/
コードの読み方ということで、最近書いている話題とマッチしているので参加してみました。
みなさんどんなふうにコードを読んでいるのかな？って気になっています。
根気の入るコードリーディングをする時のアプローチ
Shibusawaさん
https://speakerdeck.com/fumiyashibusawa/lt-omotesando-rb-2020-01-09
ソースコードを読むまえに抽象化して考えてみようという話でした。
Shibusawaさんは図を書いたりして理解しているそうです。そしてそのための補助ツールとして
をお勧めしています。
特にRailsのREADMEはとても親切とのこと。
感想
読む側としてはとても重要なREADMEやドキュメント。逆に書く側としてはちゃんと補助となるように揃えておきたいですね。
bundle update PRの読みかた
sue445さん
https://esa-pages.io/p/sharing/8985/posts/202/5544484d73b2b3828ccc-slides.html#/
sue445さんは個人のソフトウェアでは毎日bundle updateしているそうです。
また、ピクシブでは毎週月曜日の朝9時にbundle updateのPull requestを作っているそうです。
次のようなことをしているそうです。
- gemごとにcompare linkとリリースノートのURLを全部書き出す
- リリースノートがある場合
- リリースノートがない場合
プロダクトのコードを読むより先にテストコードを読むと理解が早いそうです。
感想
テストコードを先に読むのはなるほどと思いました。
わたしはテストコード読むのが苦手だなって気持ちがあります。
テストコード何をテストしているのか分りにくいものが多いなーって感じです。
逆に言うとテストコードは意図が分りやすいように3-phaseを守って読みやすいコードを心掛けたいなと思いました。
どうやってコードを読んでいるか
shinsokuさん
よく使うツール
感想
gem-srcではなくghq派もいるのだなーと思いました。
RubyMineの便利機能を紹介してみる
森塚真年さん
RubyMine使っている人意外といました。
森塚さんのお勧め機能は以下のようなものでした。
- rails consle(デバッグモード)
- Find in Path(= grep)
- annotate(= blame)
- RubyMineでPull requestが見られる
- ストラクチャ(ファイル内のアウトラインが見られる)
- クラス図の作成
感想
ちょっと便利さがよくわからなかったです。他のツールでもできそうなものだったのでマウス捌きに自信のないわたしには無理そうだと思いました。
Visual Studio Code で効率よくコードを読む
HolyGrailさん
今度はVisual Studio Codeの話です。
拡張機能にたよる
- Ruby
- シンタックスハイライト、デバッガーなどの基本的なRubyの補助機能
- Bracket Pair Colorizer
- Ruby Solargraph
- Bust A Gem
- gemへのコードジャンプ支援
gem install ripper-tags
- GitLens
感想
Bust A Gemは便利そうと思ったけど、ripper-tagsを使えばvimでも出来そうなので乗り換え機運は来なかったです。
実例で見るコードリーディングのすすめ
makicamelさん
https://speakerdeck.com/makicamel/lets-enjoy-code-reading
世界中の人(人口69億人)で2人ずつペアをつくってじゃんけんをして勝ち抜き戦をしたら33回勝てば優勝できるそうです。
2**33 > 69億
Integer#powerのMRIのソースコードを読んでみたらCで書かれていてよくわからないので、Rubinusのコードを見たらRubyのコードだったので読めそうだと思ったそうです。
簡略化したメソッドを書いたり、printデバッグしたりしてアルゴリズムを理解して解説されていました。
感想
メソッドを簡略かしてみるというのは良いアプローチのように思いました。ロジックの理解にはロジックに絞りこんで理解できるようにするというのはいいですね。
逆に書くときにはロジックはなるべく分離されていたほうが読みやすくなるように思いました。
ActiveRecordのコードを読んでみる
おしょーさん
http://secret-garden.hatenablog.com/entry/2019/12/01/154607
いろいろなテクニックを紹介されていました。
Method#source_location
- 2.7だとmethodを表示するだけで
source_locationが含まれている
p __method__
$debug = trueと後置のif $debug
using BindingDebug
- vimで検索数を表示
- これどのpluginでやっているのか聞くのを忘れていました
binding.irbcaller
感想
私もprintデバッグ派なので好感持てました。
ソースコードリーディング、いろいろな人がいろいろなテクニックを紹介していてとても面白かったです。
また、こういう会をやってほしいと思いました。
追記
vimの検索数を表示するやつはosyo-manga/vim-anzuのようです。(idからしておしょーさん本人の作のものでしょうか？)
今日で8日目です。2020年になってから。
実はこのブログを毎日書き続けています。まだ1週間ですけど。
3日坊主のわたしにとっては大分がんばっているほうです。
なぜブログを書き続けているかというと文章を書く訓練をしたいなと思ったからです。
これは今年の抱負でも書いたことです。
毎日書き続けていれば文章が上手くなるかというとそんなことはないかと思いますが、
書く早さを上げていかないと上達はしません。書くこと自体に時間が掛っていては文章を良くするというところまで一定の時間で辿りつけず、そういうことが疎かになってしまうからです。
これはプログラミングにも言えます。プログラムを早く正確に書けなければ試行錯誤も沢山できないし、その分、設計を良くしたり、読みやすさ、メンテナンスのしやすさみたいなとこのに気を配る余裕は生まれません。
早く書くには沢山書いて訓練をする必要があります。とにかく沢山書くことです。
アニメ「SHIROBAKO」で絵麻が伸び悩んでいるときに、先輩の杉江さんが「早く書くには上手くなる。上手く書くにはいっぱい描く。いっぱい描くには早く書く。」ということをアドバイスしていたのが印象に残っています。
おそらくいろいろな技能で言えることなんだと思います。だから「好きこそ物の上手なれ」なんていうことわざがあるのでしょう。
好きでなければとにかく沢山やるなんてことはなかなか出来ないですからね。
というわけでとにかく書くということをしばらく続けていこうかなと思っています。
それで、何故文章を書くのか？ということについてです。
同人誌を書きはじめたのは、3年前くらいの技術書典です。その時はRubyKaigiなどで発表してきたOpalのフレームワークの話をどこかにまとめたいという気持ちから始めました。
技術書典での自分で書いた本を売るという体験はとても刺激的で楽しいものでした。
売り上げがどうとかよりもこの体験こそが同人誌の醍醐味です。
私たちプログラマは多くの本を読みます。それは純粋に技術の解説から方法論だったりよりジェネラルなものであったり。その中には、心を動かされたり人生を変えるような力を持つものもあります。(例えば達人プログラマなどはそういう類かもしれません)
人の人生に影響を与えることを目指したいわけではありませんが、これまでプログラマとして考えてきたことを伝えられる人になれるといいなと思って執筆活動を続けていきたいと思っています。
みなさんRubyで開発していると様々なgemを使うと思うのですが、時にgemの不具合に出会ったり、このgemにこんな機能があったら良いのにということを思うことがあるでしょう。
そんな時にはそのgemのソースコードを修正したりするかと思います。修正したコードはどうしていますか？
自分(またはオーガニゼーション)のリポジトリのフォークにブランチを切ってパッチを当てて…
なんてしていませんか？
もちろん、自身のプロダクトでとりあえずそのパッチを使いたいという場合はそれでよいでしょう。
でも、そのあと対象のgemもバージョンが上ったりするたびにパッチを適用したりメンテナンスが大変です。
そうです！アップストリームにpull requestを投げますよね！
今日はここまでの一連の流れをgit-srcをつかってどうやるかということを書きたいと思います。
まずは、git-srcのインストールです。
みなさん当然rbenvを使ってRubyをインストールしていると思います。git-srcはrbenvのプラグインですのでrbenvのインストールされているディレクトリにインストールします。
$ git clone https://github.com/amatsuda/gem-src.git "$(rbenv root)/plugins/gem-src"
次にgemのソースコードの置き場所を作って、設定ファイル(~/.gemrc)にそのディレクトリを指定します。
gem-srcのREADMEには~/srcを推奨していますが、私はgem以外のソースコードも~/srcディレクトリに置いているので~/src/gemsにしています。
$ mkdir ~/src/gems
$ echo "gemsrc_clone_root: ~/src/gems" >> ~/.gemrc
これで準備は完了！gem install hogeとかbundle installする度に~/src/gemsディレクトリにgemのソースコードが放りこまれます。
~/src/gems/opalにopalのソースコードがgit cloneされています。
opalのソースコードに修正を加えたい場合はおもむろにそのディレクトリで
というコマンドを打ちます。
おっと、説明を忘れていました。みなさんはもちろんGitHubを使っていてhubコマンドがインストールされていますよね？
これであなたのGitHubリポジトリにフォークがつくられました。
opalの不具合を修正したり、新しい機能を追加したりするパッチを書きましょう。
ここでちょっと注意が必要です。このlocalリポジトリのHEADはmasterでお使いのopalのバージョンのタグをチェックアウトしておく必要があります。
修正版のopalを使うにはGemfileに次のように書いておきます。
gem 'opal', path: '~/src/gems/opal'
こうすることでbundlerは修正版のソースコードからファイルをロードしてくれるようになります。
パッチが出来上がったら、プロダクトもこのパッチを適用したバージョンを使いたくなりますよね。
自分(またはオーガニゼーション)のリポジトリにpushしてGemfileを書き換えます。
gem 'opal', github: 'https://github.com/youchan/opal' # youchanのところは適宜書き換えてください。
最後はアップストリームにpull requestを送って完了です。
アップストリームでパッチがマージされて、gemの新しいバージョンが使えるようになったらGemfileを戻してやればOKです。
Rubyはオープンソースでの開発が出来る仕組みが普通にあって、自然とオープンなエコシステムの中で開発できる素敵な環境です。
仕事で書くコードもオープンソースのコードもシームレスに開発してOSS開発を楽しんでいきましょうね！
もとネタの https://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview39.html この記事とても良いので読むと良いですね。
ドキュメントを読まないでというのは極端だと思いますが、ドキュメントを読んでもよくわからないとかドキュメントが(充分で)ないということは良くあることなので、そういう時にはソースコードを読みます。
私はキャリアとしてはJavaからはじめて現在はRubyを主に書いているという感じです。ライブラリのソースコードを読むというのはRubyを使うようになって特にやりやすくなったなと感じています。
Javaのようなコンパイルする言語では、ライブラリはコンパイル済みのオブジェクトコードになっているものが提供されていてソースコードについては別で扱われるということがよくあります。
オープンソースであればソースコードにすぐにアクセスできるのですが、そうでない場合もあります。時には(ライセンスで許されていれば)逆アセンブルして解析するなんてこともあります。いずれにせよ手間であったり、ソースコードを見られなかったりします。
Rubyではソースコードを直接読みこむためライブラリもソースコードで提供されます。GitHubのおかげでブラウザからのソースコードへのアクセスも楽になりました。(逆に言うと、ソースコードを公開したくないベンダーにとってはデメリットではあります。)
Ruby(だけの話ではないのでJavaとの対比でいうと)は言語のしくみ上でもソースコードを公開するという文化が根づいているなということを良く感じます。
GitHubがRubyで作られていることもうなづけます。
Rubyが初心者におすすめできる言語というのはこういう側面からも言えますね！
最後にRubyでライブラリ(gem)のソースコードを読むためのTipsをひとつ
gem-srcというツールを使いましょう。
gem-srcを使うとgem installすると同時にgemのソースコードのクローンをgitリポジトリから取ってきてくれます。
gem自体ソースコードなのになぜこのようなことをするのかというと、元のgemに影響を与えずにソースコードを修正することが出来るからです。
また、修正したコードをそのままPull Requestすることも出来ます。
明日はgem-srcの使いかたをもうすこし具体的に書こうかと思います。(明日はasakusa.rbの新年会なので松田さんからtipsが聞けるかもしれません)
昨日shibuya-mokumokuでやったことを書きます。
2020-01-02の記事で書いたRewriterを実際につかってみました。
実際にrewriteするOpal::Rewriters::Baseクラスを継承するクラスを作って、
module Opal
module Rewriters
class TestRewriter < Base
def on_block(node)
recvr, args, body = node.children
return super unless recvr == s(:send, nil, :rewrite_test)
body = s(:send, nil, :puts, s(:str, "Block was rewrited!!"))
node.updated(:block, [recvr, args, body])
end
end
end
end
rewriter.rbにOpal::Rewriters::TestRewriterを追加するだけです。
ここでは、rewrite_testというメソッドが呼ばれたら、ブロック内の処理を書き換えて"Block was rewrited!!"という文字列を表示するという処理をしています。
def rewrite_test
Yield
end
のようなメソッドを定義して、
のように空のブロック(ブロック内な何でもよいのですが)を渡して呼びだすと、"Block was rewrited!!"という文字列が表示されます。
今日はRubyKaigiのCFPを書くためにもくもくしてきました。
CFPを書くためと言いつつ一行も書いていないのですが、フィージビリティの検証のためにちょっとしたコードを書いたりしていました。
昨日のつづきです。
昨日はdevelopmentモードで動かすことができました。今日はproductionで動かしたり、実用的なWebアプリを書くためのアレコレをしてみましょう。
gemを読み込む
productionで動かす前にgemをどうやって読み込むの？というのをやってみます。
まずはGemfileに使いたいgemを追加しましょう。
さて、ここでapplication.rbにrequire 'hyalite'すれば良いのですが、実はこれだけではgemを読み込むことはできません。
app_loarder.rbに次の一行を追加してください。
それでは、application.rbをhyaliteをつかって書き換えてみましょう。
require 'native'
require 'hyalite'
class ApplicationView
include Hyalite::Component
def render
h1(nil, 'Hello, Hyalite!!')
end
end
Hyalite.render(Hyalite.create_element(ApplicationView), $document[".content"])
ページに"Hello, Hyalite!!"って出たら勝ちです！
Sinatraを使うようにする
みんな大好きなSinatraでHTMLも動的に生成します。
動的に生成と言ってもここではあくまでSinatraをどうインテグレーションするのかという例を示すに留めて、動的な要素はみなさんの創造性にお任せすることにします。
最も簡単なSinatraのアプリケーションは以下のようなものでしょう。
require 'sinatra'
get '/frank-says' do
'Put this in your pipe & smoke it!'
end
おっと、失礼しました。これではJavaScriptのコードを読み込むことができませんので、以下のようにerbをレンダリングするようにしましょう。
require 'sinatra'
get '/' do
erb :index
end
index.htmlをviewsディレクトリに異動して拡張子を.erbに変更します。(views/index.erb)
これで準備完了。Sinatraアプリを起動します。
productionで動かす
それではproductionで動かしてみましょう。Sinatra側は-eオプションを指定します。
$ ruby app.rb -e production
Webpackのdevelopmentサーバーを止めてしまうと、当然JavaScriptのファイルを読めなくなってエラーになります。
虚しくまっしろいページが表示されることでしょう。
JavaScriptのファイルをプリコンパイルするために以下のコマンドを実行します。
$ yarn run production_build
プリコンパイルに成功すると以下のようにファイルが生成されます。(cae2faf25ed9cfbc18b3というのはMD5ハッシュなのでビルドする毎に変わります。)
$ ls public/assets
application-cae2faf25ed9cfbc18b3.js application-cae2faf25ed9cfbc18b3.js.gz manifest.json
このハッシュ付きのファイルを読み込む必要があります。manifest.jsonの中にメタ情報が入っています。これをサーバーで読んでHTMLファイルの中に埋め込みます。安心してください、そのためのヘルパーはちゃんと用意されています。
app.rbを以下のように書き換えてください。
require 'bundler/setup'
Bundler.require(:default)
require 'sinatra'
require_relative 'owl_init'
include OpalWebpackLoader::ViewHelper
get '/' do
erb :index
end
Sinatraアプリ側でもopal-webpack-loader gemを使えるようにして、ViewHelperクラスをインクルードします。これでビューでヘルパーを使えるようになりました。
次はviews/index.erbを次のよう書き換えましょう。
<!doctype html>
<html>
<body>
<div class="content"></div>
<%= owl_script_tag('application.js')%>
</body>
</html>
サーバーを再起動したら今度はちゃんと"Hello, Hyalite!!"と表示されるはずです。
developmentモードでもちゃんと動くことも確認しましょう。
ViewHelperが格モードで読み込むファイルを切り分けていることが分ります。
この記事はOpal (Ruby-to-JavaScript compiler) Advent Calendar 2019の2日目の記事として書こうとしたものです。残念ながら記事を完成させる前に新しい年を迎えてしまったのですが、折角なので記事を完成させて公開しようと思います。
opal-webpack-loader
OpalにはRack middlewareとして動くアプリケーションサーバーとしての機能があります。この機能はSprocketsをつかってRubyからJavaScriptに変換してアセットを提供します。
ところが、この機能はOpalに組み込みになったり、gemとしてOpal本体とは別に提供されたりということ繰り返しています。(現在はopal-sprockets gemとして独立しています。)
Railsで開発している人は知っていると思いますが、Sprocketsを使って開発する場合、開発時にはSproketsによるコード変換は都度行なわれるため、ソースコードを変更してもサーバーを再起動せずにアプリケーションに反映されますし、プロダクションに対してはプリコンパイルをすることで変換済みのコードをデプロイすることが出来るようになっています。
しかし、どういうわけかopal-sprocketsにはアセットをプリコンパイルする機能がありません。もちろん自前でSprocketsを呼びだすコードを書けばプリコンパイルすることはできるはずですが…
OpalはRubyで書かれたコードをJavaScriptに変換しますからコンパイルのコストがとても大きいです。
いわゆるAltJSと呼ばれる言語はJavaScriptに変換されることを前提に言語設計されているので多くの場合はコンパイルのコストが低く抑えられています。
(TypeScriptのように型チェックに大きなコストがかかるものもありますけどね！)
コンパイルのコストが大きいとアセットをプリコンパイル出来ないことは大きなマイナスです。
RailsでもWebpackerが導入されたことにみられるように、WebのフロントエンドのアセットのビルドにはWebpackが主流になっています。
OpalでもSprocketsの代りにWebpackが使えることは大変意義のあることです。opal-webpack-loaderはOpalのコンパイルを可能にするWebpackのPluginです。
Webpackを使いますので、Webpackの機能を使ってアセットのプリコンパイルが出来ますし、環境に応じてアセットのURLを切り替える機能も提供しています。
インストール
opal-webpack-loaderは当然ですがWebpackが必要です。Webpackを使えるようにするためには、JavaScriptの実行環境やエコシステムを手に入れる必要があります。ここではyarn(もしくはnpm)を使える環境が手に入れば充分です。ここまではみなさんの環境に依存する話ですので個々に解決してくださいね。
それと、もちろんRubyとgemが使える環境も必要です。もうすぐクリスマスですので間も無くリリースされるRuby2.7のリリース準備版を手に入れるのもよいでしょう:P
それではgemをインストールしましょう。
$ gem install opal-webpack-loader
Opalがまだインストールされていない場合は依存関係からOpalもインストールされるのでこれで準備が整いました。
セットアップ
opal-webpack-loaderにはすぐ使いはじめるためのcliツールが付属しているので簡単にはじめられます。
$ mkdir owl-sample && cd owl-sample
$ owl-install flat
このコマンドは、カレントディレクトリにボイラープレートのコードを生成しますので、必ずデレクトリを作ってから実行してくださいね。
いくつかのファイルが作られるとともに以下のメッセージが表示されます。
Add the following lines to your Gemfile:
gem 'opal', github: 'janbiedermann/opal', branch: 'es6_modules_1_1'
gem 'opal-webpack-loader', '~> 0.9.9'
owl currently works only with above opal branch. If you have a existing "gem 'opal'", please replace it with above line.
Also check above output for files ending in '_owl_new' and merge their contents with the existing files.
After that run according to your preference either:
yarn install
or:
npm install
and then:
bundle install
For further instructions see http://github.com/isomorfeus/opal-webpack-loader
メッセージにしたがってGemfileをつくります。
実はopal-webpack-loaderはOpalのまだマージされていない機能を使って実装されています。作者のフォークを使っています。
Gemfile
gem 'opal', github: 'janbiedermann/opal', branch: 'es6_modules_1_1'
gem 'opal-webpack-loader', '~> 0.9.9'
そして、以下のコマンドを実行しましょう。
$ yarn install
$ bundle install
Opalのコードを実行しましょう
開発用のサーバーを起動してみましょう。
次のコマンドを実行します。
webpackの開発用サーバーが起動してコンパイルが走ります。
コンパイルが問題なく終ったらブラウザで
http://localhost:3035/assets/application.js
にアクセスしましょう。
コンパイルされたJavaScriptのコードが見られるはずです。
このままでは何も起りませんので、Opalのコードを書いて実行してみましょう。
opal/application.rb
require "native"
$$.document.addEventListener("DOMContentLoaded") do
$$.document.getElementsByClassName("content")[0].innerHTML = "<h1>Hello Opal</h1>"
end
このOpalのコードを読み込むようにopal/opal_loader.rbに次の一行を追加します。
opal/opal_loader.rb
そして次のようなhtmlファイルを作成してブラウザで読みこんでみましょう。
index.html
<!doctype html>
<html>
<body>
<div class="content"></div>
<script type="text/javascript" src="http://localhost:3035/assets/application.js"></script>
</body>
</html>
どうでしょう？期待通りの結果になりましたか？
明日はプロダクションのためにプリコンパイルする方法とsinatraを使って実際のWebアプリケーションのように動かすようにします。
OpalのコンパイラにはRewriterという仕組みがあります。
OpalのコンパイラはRubyのコードからparser gemを使ってASTを構築し、ASTをトラバースしながらJavaScriptのコードを生成していきます。
RubyのASTはそのままJavaScriptに変換するには不都合がある場合があります。
この不都合を回避するためにあらかじめASTを書き換えるしくみを持っています。
例えば次のようなケースです。
のようなケースでASTの書き換えを行ないます。
(ほかにもこのあたりを見るとさまざまな書き換えをおこなっていることがわかります。)
opal_engine_checkのように本来は評価時にチェックするようなものもコンパイル時にチェックすることが出来るようになっているのです。
今年の抱負を書こうと思います。
去年はいろいろ大変なことが起ってやりたいなと思っていたことがあまりできなかったので、今年はもうすこし強い意思を持ってやりたいと思う。
本を書く
去年は「マンガでわかるRuby」を1巻、2巻と書いてきましたが、続編も書かないと完結しないということで3巻までは書こうと思っています。
あと、これ書いていいのかわからないのでぼやかして書いておくと、もうちょっと発展した話もありますので書いていこうと思います。
コードを書く
去年は8月からマネジメントをやることになったり、プライベートでもなかなかコードを書く時間を取れなかったので、今年はコードを書けるといいなと思っています。書きたいものは沢山あります。
英語がんばる
毎年言っている気がするけど、ちゃんと習慣化して勉強したいなあ。
日記を書く
この日記放置されすぎなので、もっと頻繁に更新したいです。
技術の文章を書くということをもっともっと鍛えていきたいなという気持ちです。
ちゃんと日記書こうかなと思ったので、日記です。
技術書博覧会に出展してきました。正確に言うと「湊川あいのわかば家。」というサークルのお手伝いで行ってきました。
お手伝いと言っても共著の作品もあるので、まあ一緒のサークルで参加したような形です。(いつもおまかせ状態ですいません>湊川さん)
さて、日記なのでつれづれなるままに書きます。
控え目に言って、今回の技書博は最高でした。
カフェは無料で提供されるし、
お弁当は出るし、
懇親会も会費以上のクオリティで食べるものも、飲みものも最高でした。
ここ数年、技術書典に出展したりしていますが、技術書典とは違った良さがあります。
そこには自分が技術書典に求めていたものの原点のようなものがあります。
技術書典は良くも悪くも規模が大きくなって、自分が求めていたものと違った方向性があります。
(それはそれで発展的でよいことですし、その発展の中心にいる湊川さんと共著させてもらっている身ですのでとてもありがたい話でもあります。)
技術書を書いて儲けるという景気のよい話の多い技術書典ですが、全然儲かっていない自分としては、イベント自体を楽しめる趣向のある技書博があるのはとてもうれしいです。
(とは言え技術書典くらいの規模がないと黒字にすらならないので棲み分け大事ですが)
技書博では参加者がまだ少ないということもあってスペースにゆとりがあり、本を求めていらした方とゆっくりお話することができます。
一般参加の方たちもちょっと層が違う感じで、技術書典のあの軍場のような雰囲気が苦手な人たちがゆったりとみられる雰囲気を求めて来ているのかなとも思いました。(個人の感想です)
技術書典とは一味違ったもう一つの技術書同人誌即売会出掛けてみてはいかがでしょう？
次回は2020年6月27日を予定しているそうです。
しがないラジオでもちこさん(@mochikoAsTech)と湊川さん(@llminatoll)がゲストで技術書典5についてお話ししてました。
前回のエントリーの通り私は湊川さんと本を作ったのですが、その時の組版についてしがないラジオの中でも言及されていたので、ちょっと解説記事を書こうと思います。
まず、基本的にはVivliostyleによる組版でVivliostyleまかせです。私はあんまり何もしてない感じなので簡単ですよ。
Vivliostyleについては、vvakameさんの「CSS組版やっていき！」やpentapodさんの「CSSではじめる同人誌制作 増訂版」が詳しいです。
そちらを参考にしてください。
vvakameさんの本はRe:VIEWからCSS組版をするものでした。
私も前作2作はRe:VIEWで書いていたので、Re:VIEWから書こうと思いました。
ところが、私が書きたかった内容が黒猫先生としんらちゃんとの対話形式で話を進めていくということでした。
そのため吹き出しのような表現ができるということが要件になります。CSS組版を選んだのもそのためです。
一方、VivliostyleはHTML+CSSで自由に組版できます。Re:VIEWを使わなくてもHTML+CSSが作れればよいわけです。逆にRe:VIEWを経由すると制約が多くなって、ちょっと自由にレイアウトするのが難しかったりします。
私はRe:VIEWで本を書くときでも、最初はMarkdownで原稿を書いてからRe:VIEW形式に変換しているのですが、
それならばRe:VIEWを経由しなくてもMarkdownから直接HTMLを生成できればよいのではないかと考えたわけです。
MarkdownからHTMLを生成するのはredcarpetを使えばお手のものです。
私はGibierというプレゼンテーションツールを作っているのですが、そこでもredcarpetで変換しています。
(GibierではRubyのコードを生成しています。)
redcarpetからHTMLを生成するのは簡単です。
require "redcarpet"
markdown = Redcarpet::Markdown.new(Redcarpet::Render::HTML, autolink: true, tables: true)
markdown.render File.read("content.md")
のようにすればHTMLが生成されます。(お好きな名前でファイルに保存してください。)
そのままVivliostyleに読ませるだけでも立派に技術書になります。
これに前述のCSS組版の本などを参考にCSSを書けば見栄えもよくなってテンションがあがります。
さて、肝心の会話のシーンですが、私は以下のような会話の文章を書いたら吹き出し付きのスタイルが当るようにredcarpetのRenderクラスをカスタマイズします。
[begin dialog]
黒猫先生「わしは黒猫じゃ名前などない。」
しんらちゃん「名前がない！？それじゃあ呼ぶのに不便だから、黒猫の先生ってことで黒猫先生と呼ばせてね。」
黒猫先生「ふむ。物事に名前をつけることは重要なことじゃ、そう呼ぶとよい。かのまつもとゆきひろも『名前重要』とよく言っておる。」
...中略...
黒猫先生「たしかに自然言語処理や機械学習のための道具だてはPythonのほうが多く揃ってきている。しかし、Pythonではそういった道具をうまく使いこなすことが重要になるが、Rubyではそれを作ることから始める必要がある。ゼロから学ぶにはかえって良いと思うぞ。」
しんらちゃん「うーん。なんか納得できないなぁ…」
[end dialog]
[begin dialog]と[end dialog]は会話のはじまりとおわりを表すマークです。黒猫先生「...」とかしんらちゃん「...」というのは正規表現で引っ掛けます。
上の文章は以下のようなhtmlになります。
<div class='dialog'>
<div class="speech kuroneko">
<div class="icon"></div>
<div class="baloon">
<p>わしは黒猫じゃ名前などない。</p>
</div>
</div>
<div class="speech shinra">
<div class="icon"></div>
<div class="baloon">
<p>名前がない！？それじゃあ呼ぶのに不便だから、黒猫の先生ってことで黒猫先生と呼ばせてね。</p>
</div>
</div>
<div class="speech kuroneko">
<div class="icon"></div>
<div class="baloon">
<p>ふむ。物事に名前をつけることは重要なことじゃ、そう呼ぶとよい。かのまつもとゆきひろも『名前重要』とよく言っておる。</p>
</div>
</div>
...中略...
<div class="speech kuroneko">
<div class="icon"></div>
<div class="baloon">
<p>たしかに自然言語処理や機械学習のための道具だてはPythonのほうが多く揃ってきている。しかし、Pythonではそういった道具をうまく使いこなすことが重要になるが、Rubyではそれを作ることから始める必要がある。ゼロから学ぶにはかえって良いと思うぞ。</p>
</div>
</div>
<div class="speech shinra">
<div class="icon"></div>
<div class="baloon">
<p>うーん。なんか納得できないなぁ…</p>
</div>
</div>
</div>
このソースコードはgistに公開しています。https://gist.github.com/youchan/52569644ff4ce3fef48cccee96f16c33
実際に使ったソースコードは本当にこれだけです。とてもシンプルでしょ？
このようにRe:VIEWなどのつくりこまれたシステムを使わなくてもそれなりのものが作れます。
むしろこういう形のほうが自分で自由にタグを設定したりできるので自由度が高いです。
本に合わせて都度コードを書いてもさほど手間ではないので、私は結構この方法がとても気にいっています。
それとちょっとポジショントークをしてしまうとRubyはやっぱりこういうときにサクサクとコードを書いてそれなりのものが作れてよいです。こういうちょっとしたツールを作っているときがRuby最高だなって思います。
Ruby on RailsだけではなくこういうところでRubyの良さをもっと知ってもらえたらいいなって思っています。
そういうわけで、しながいラジオのなかでも湊川さんが紹介されていましたが、Rubyの入門書を書こうと思っています。
こういう実用的なプログラミングではないですがトイプログラミングでRubyの楽しさが伝わるといいなと思っています。
乞うご期待ください！
昨日書き忘れましたがCOMIC ZINとBOOTHでオンライン販売しています。
内税・外税、送料に若干の違いがありそうです。
Boothのほうは入庫待ちになっています。
COMIC ZINのほうは実店舗での販売もしているそうです。
今回は完全にこれでした。
人気サークルにちょっと混ぜてもらえるとか、良い感じの表紙を描いてもらえたとかで浮かれてしまい、つい400部も印刷してしまって、まさに爆死しました。
隣でわかばちゃんの新刊がばかすか売れていくのを尻目に、まったく減っていかない自著の山に呆然自失となってしまいました。
よい話が多い技術書典ですが、こういう事例もあるということをちゃんと伝えるべきかなと思いますので、書き記しておきます。
もともと、数十部頒布できればよいマイナージャンルのマイナーサークルです。よい場所で出させてもらったのはとても良いことだったのですが、身の程を知るというか、想定の読者がどれくらいいるかということはちゃんと考えて出したほうがよいというのが今回の反省です。
それでも、100部近く出せたのはひとえに湊川さんのおかげだと思うので、次回は自戒して望もうと思います。
敗因分析
結果は残数でカウントして97部です。
まあ、負けたと言っても実際には自分としては過去最高の頒布数です。印刷部数を完全に読み間違えていたということでした。
難しかったのは、やはり人気サークル内でやったということですね。被チェック数も当てにすることはできません。
湊川さんが新刊1300部とか印刷しているのをよそに100部という訳にもいきませんでした。200部くらいが着地点かなという気持ちでいたのですが、完全に技術書典の雰囲気に飲まれて倍プッシュです。実際200部出ればトントンで赤字にはならないのでそれでいこうということになりました。
それと客層がぜんぜん違うという問題もありました。湊川さんのブースに来る人たちは完全に湊川さんのマンガを求めて来ます。内容も入門的なものが中心ですので、Rubyで自然言語処理というちょっとマニアを通り越して変人な内容のものは見向きもされない感じでした。
売れかたとしては新刊3冊ください。みたいな湊川本と一緒に購入みたいなパターンが多く見られて、そうやって買っていかれたかたには大変もうしわけない気持ちです。
逆に内容をパラパラめくってた方は確実に買わないという感じでしたので、完全に内容で選ばれていないなーという感じでした。
残った300部どうする？
まあ、今回届けられなかった人に少しづつでも買ってもらえたらなと思います。
もともと、この本はRubyで出来ることを増やす活動の一環です。私がRubyKaigiで話すことや技術書典に本を書くことの原動力はそのへんにあります。OpalはフロントエンドもRubyで書けるということですし、今回はRubyで機械学習や自然言語処理ができるということ伝える内容です。
そういったことに少しでも興味を持ってもらえればということで本を書いているので、やはり届くべきところに届いて欲しいです。
今回の「猫と森羅と日本語とRuby」はRubyで自然言語処理に挑戦するというめずらしい内容の本でもあります。
そこに価値があると信じてやっていることなので活動していくなかでその価値が認められるように続けていけたらいいなと思っています。
今後もRubyで自然言語処理を「猫と森羅と日本語とRuby」シリーズとして書いていく所存です。新刊と一緒に売っていって、なくなるころには少しはこの分野が盛り上っているといいなと思う次第です。
追記 ↲
購入方法はこちら 見てください。↲
明日は技術書典5ですね！会場もさらに広い会場に移ってよりパワーアップした技術書典です。参加サークルも500サークルということで過去最大です！
そんな技術書典5ですが、私は残念ながらサークル参加に落選しました。
つまり500サークル以上の申し込みがあったのですね。すごい！
こんなに技術書を書きたいという人がいるということには驚きです！
技術書典に行けばきっとよい本にめぐりあえるでしょう。
Let's go!
私は残念ながら落選してしまったのですが、「わかばちゃん」シリーズの著者である湊川あいさん(@llminato)に一緒に出しましょうというお誘いをいただいて湊川さんのサークルに間借りさせていただいて出展できることになりました。
湊川さんには感謝感謝です！
しかも、表紙と挿絵まで描いていただきました。(下の画像が表紙です。)
そういうわけで、タイトルは「猫と森羅と日本語とRuby」です。
以下は本のはじめにに書いた内容です。ここにタイトルの理由とどうしてこの本を書こうと思ったかが書かれています。
「猫と森羅と日本語とルビー」この本のタイトルは私がこの本に詰めこもうとしたものすべてを表わしています。
猫はこの同人誌を書くためにつけたサークル名「みさきとミギー」に由来します。
みさきとミギーは私の飼い猫です。飼っているというより同居していると言ったほうがいいでしょう。
私は毎日猫たちとゴロゴロしながら猫のように過しています。ですので、猫は私自身のことであり、私の私的な指向でやっている技術を本にまとめたという気持ちが込められています。
おそらく猫のようにころころと話題を転換しながら進行することでしょう:p
2つめの森羅はこの本のメイントピックである森羅プロジェクトのことです。
2つめの森羅はこの本のメイントピックである森羅プロジェクトのことです。
森羅プロジェクトはWikipediaから固有表現を抽出して構造化するということを行う評価型のプロジェクトです。
森羅プロジェクトは評価型のプロジェクトでありながら言語資源をつくることを同時に行うということでこのプロジェクトの成果は世に還元されるという意義のあるものです。
私が森羅プロジェクトに参加しようと思ったのは、この本のタイトルの最後の2つ、「日本語とルビー」というところに理由があります。
日本語とタイトルにつけたのは日本語の自然言語処理のことです。森羅はもちろん日本語の自然言語処理の技術を発展させるために起こされたプロジェクトであり、日本語の自然言語処理のプログラミングを必要としています。
ところが、日本語の自然言語処理のためのプログラミングツールは決して充実しているとは言い難いです。
ルビーはもちろんプログラミング言語Rubyのことです。
私はRubyという言語がだいすきです。何故好きかというと、いろいろ理由はありますが、大きく2つの理由があります。
ひとつは良く言われることですが、Rubyがとても手に馴染む使いやすい道具であるということです。
もうひとつはコミュニティにあります。Rubyのコミュニティはいつもあたたかく、そしてプログラミングが大好きな人々の集りで、皆で技術的な課題を一緒になって解決しようという謎の団結感があります。
そのコミュニティのひとつにRed Data Toolsというコミュニティがあります。Red Data ToolsはデータサイエンスのためのツールをRubyで作っていこうという集りで、コミュニティを跨って協力してやっていこうというポリシーを持っています。
私はそのRed Data ToolsのメンバーとしてRubyの自然言語処理のツールを開発しています。
またRuby自体、日本人が作った言語でいまでも多くの開発者が日本人です。自然言語処理の中でも特に日本語にフォーカスするとRubyでできるようにすることは意味のあることだと思います。
私は大好きなRubyとそのコミュニティと一緒に自分の目下の興味関心のある自然言語処理の課題にチャレンジしていて、それについてまとめたものが本書ということになります。
なんと、RubyKaigiから1ヶ月が経ってしまいましたが、前回の1日目の話に引き続き2日目のはなし。
この日は自分としては何もない日なのですが、たまたま、JonanのThe Jonan Showに出たので、その話をします。
私がThe Jonan Showを始めて満たのは、Rails Conf 2018のときです。そのときに書いた記事はこちらです。
The Jonan ShowはRubyKaigiではデカ外人として知られているJonanがRubyのカンファレンスでロビーの一角で参加者をつかまえてペアプロをして、それをストリーミングをするという番組です。
私は前回にリモートで一人で勝手に参加していたので、私がThe Jonan Showに出たいと言ったら、Jonanが私が書いたワンライナーがわからなかったので解説してほしいということで、
解説をする配信をしました。
https://www.twitch.tv/videos/268014558
Jonanが最初に見たときに全然わからなかったといっている通り、ワンライナーで書くためにちょこちょこ変なテクニックをつかっています。
ギャラリーの中からも面白かったという声がありましたので、よかったら見てみてください。(私の英語力のなさが暴露されていますが)
そして、RubyKaigi2日目といえばドリンクアップですが、私はコード懇親会に参加しました。
私はお酒(特に日本酒)が好きなので、普通にドリンクアップに参加するというのもよかったのですが、
ただ飲んで(しかも、だいたい知っ顔ぶれとばかりしゃべって)いるだけなら東京でもできるし、せっかくRubyKaigiでコードを書く人たちが集ったので、コードで懇親するというコンセプトのこの懇親会に参加することにしました。
コード懇親会は最初に自分が参加するOSSのプロジェクトを選んで、同じプロジェクトを選んだ人同士でコードを書きながら懇親するというものです。
私はRed Data Toolsで開発中のChartyのプロジェクトに参加しました。
私たちのグループはおしゃべりするばっかりでコードを書くことについてはあまり進められませんでしたが、同じプロジェクトに興味のある人と話ができたり、
なんと、Matzが我々のテーブルに来てくれたりしてとても楽しい時間を過すことができました。
たまにはこういう変りダネの懇親会に参加するのもよいなと思うので、もっとこういう試みが増えるといいなって思いました。