2018-02-10

決定木を実装せんと欲す

というか実装してみました。

https://gist.github.com/youchan/185c56328e4244f1aaa02017bd6d4897

【初・中級者向け】ランダムフォレストとアンサンブル学習 #2 - connpass

という勉強会というかセミナーがありまして、ランダムフォレストについて学んだので決定木の実装をしてみようと思いました。 (フォレストにしてみたいので、Kaggleあたりから程よい課題をみつけられたらやってみようかと思います。)

課題はセミナーのなかでもあつかったscikit-learnのこれ

学習データのirisはなんと、red-datasetsというgemでRubyから使いやすい形で提供されています。

結果、このように

Decision Tree

scikit-learnの結果となんだか違うぞー……

プログラムを見るとわかりますが、ツリーをつくるのに単純に平均情報量の大きいものを採用しています。(グリーディなアルゴリズムです)
単純にこのアルゴリズムでやるとなかなかリーフが決まらずに下図のような長大なツリーになってしまいます。

Over fitting

このような繰り返しを防ぐために枝刈りをしてしまいます。(56行目)

枝刈りをするほかにも、最大の深さを決めてその中で最適な解を探すようなアルゴリズムも考えられるでしょう。(深さの制約があれば線形計画法で解くこともできるでしょう。)
scikit-learnはそのようなアルゴリズムであろうことが予想されます。
このへんの詳しい資料を見つけられなかったのですがscikit-learnのコードを読むなりすれば参考になるでしょう。
今回はナイーブに実装してみたということでここらへんで。

前回のCKY法同様、ちょっと合間時間に実装できるような小さな問題をちょこちょこ解いて機械学習力をちょっとでも上げていこうかなと思ってます。
つぎは何やろうかなー?


2018-02-04

スマートウォッチのSWINGSが届いた

去年の秋くらいにKickstarterに出ていたSWINGSというスマートウォッチにバックしました。
プレッジとしてSWINGSがひとつ送られるということで、昨日そのSWINGSが手元に届きました。

Kickstarterのページを見てもらうと分るのですが、一見、普通のアナログ時計です。
スマートウォッチに必須の液晶ディスプレイがありません。しかし、このSWINGSには以下のようなスマートウォッチとしての機能があります。

  • 通知機能
  • フィットネストラッキング
  • 睡眠トラッキング
  • ミュージックコントロール
  • カメラコントロール
  • 着座リマインダー(長時間座っている状態をリマインドするあれです)

Appleウオッチのようにアプリを入れたりして何でもできるというわけではないですが、スマートウォッチとしてよく使われる機能がまとまっているのではないかと思います。
その他に時計としても、

  • ストップウォッチ
  • 防水(100m)
  • タイムゾーン同期

などあります。

私はスマートウォッチに求めるのが通知だけで、あとは普通に腕時計としておしゃれな時計が欲しいなって思っていました。 (自分で作ろうとも考えたこともありますが、さすがに腕時計のサイズに収めるためには加工技術に乏しいので断念しました。)
そして、その理想的な形のスマートウォッチができるということでKickstarterで一早く手に入れることにしました。

昨日一日時計をはめていて気づいたことは、まず、腕時計は便利ということです(笑)。

携帯電話を持ちはじめたころから、腕時計というものは使わなくなったのですが、久しぶりに腕時計をしたら時間を見るためにスマホを鞄から取りだしたりということが結構わずらわしいことだったんだなと実感しました。
特に自宅にいるときには、時間を見るのが面倒でGoogle Homeに「今、何時?」と聞いていたりしてたので、腕に時間がついているのはとても便利に感じました。

というわけで、私が本当に欲しかったものは腕時計だということが判ったので、それだけで腕時計を買った(しかも気に入ったデザインで!)ことは正解です。
そして最大のオマケ機能である、通知がこれがまた便利で、昨夜は友達と目黒で飲んだのですが、待合せなどの連絡にtwitterのDMでやりとりしていました。
twitterからの通知があると、腕がブルって震えて、すぐに伝えてくれます。そこでスマホを取りだす余裕があれば、スマホを取りだして通知を確認します。
その他にもLINEの通知もすぐにわかります。
これは便利です。超ライフチェンジングです!

あとは、睡眠トラッキングやフィットネストラッキングなど他のオマケ機能もいろいろ試してみようと思います。

日本ではMakuakeでも支援を集めているようです。Kickstarterのときにくらべて支援額が大きくなっていますが、おひとついかが?


2018-02-01

CKY法のアルゴリズムを実装してみた。

レトリバでは「放送大学テキスト「自然言語処理(著:黒橋教授)」読書会」というのをやっていて、構文解析という章でCKY法( CYK法と呼ぶ流派もあるらしい)がよく分らなかったので復習としてRubyで実装してみました。

Gistに置いておきます。


2018-01-31

自作キーボードのスヽメ

ということで、先日の自作キーボード大会の話がレトリバセミナーで話されました。


2018-01-20

Foobarキーボードつくったった

あけましておめでとうございます。今年もよろしくおねがいいたします。

昨年は転職をして、新しい会社で新年を迎えたわけですが、新年早々に社長から、 キーボードつくりましょう!とのお言葉。なにごと!?と思ったら、Foobarという自作キーボードの基盤を作ったらしく、 沢山の基盤とパーツがあるので一緒につくりましょうということでした。

社長が自作キーボードにはまるまでには伏線があって、レトリバACM-ICPC国際大学対抗プログラミングコンテストの2017年アジア地区つくば大会のスポンサーをしていまして、参加学生向けにノベルティを配ろうということになりました。
みなさん覚えていますでしょうか?RubyKaigi2017のときのMisoca社のノベルティを!そう!Cherry MX キースイッチ用のキートップです。私もBaroccoを使っているので、もちろん頂戴いたしました。
弊社でもこれは真似したいということで、レトリバキートップつくりました。

でもこれってCherry MX軸つかってるひとじゃないと使えないじゃないですか(レトリバでは東プレ用の変換アダプタも配布しましたけどね☆)。それだけでは使えないんじゃおもしろくないので作りました。光るキーホルダーを

というわけで凝り性の社長が自作キーボード沼にはまるまでの伏線は用意されました。幸い年末年始休みもありはまるための時間も十分です。そんなわけで新年に出社するなり自作キーボード仲間に誘われたという次第です。
私もBaroccoを使っていることから分るとおり、キーボードにはこだわりたいクチだし、出来ることなら自作したいと思っていたところなので、仲間入りさせてもらうことにしました。

制作過程は同じく自作キーボード仲間の@eiichiroiの一連のツイートでどうぞ。

Foobarキーボード

さて、ここからは私の解説と奮闘のあとを記しておきたいと思います。

Foobarキーボードは@eiichiroiのツイートで分るとおり、分離型30キーの超小型のキーボードです。 40%キーボードと呼ばれる一連のシリーズの一つです。(Foobarはさらに小さく30%です。)

http://www.40percent.club/2017/09/foobar-10.html

PCBはGithubにありますので、自分でつくることができます。 ちょうどEasyIDAで100mm * 100mmのPCBが5枚で2$のキャンペーンをしています。Foobarの基盤はとても小さいのでこれで作ることができます。(お得情報!)

あとのパーツはAliExpressなどで買えるので適当にそろえましょう。

制作のほとんどは半田づけです。半田づけが得意なひとはよいですが、私のような初心者は慎重にね!
(私は数カ所半田がちゃんと繋っていなくて最初はうまく動きせんでした。)
以下は私が経験したトラブルと注意点です。

ダイオードは極性があるから注意(四角いランドが正)

これは電子工作の基本中の基本だと思いますが、なんと!基盤に極性が書いてありません。
どうも(自作キーボード界隈で?)ランドが四角いほうが正極というお約束があるそうです。
向きを間違えないように注意して作ってね。

マイコンをつけるピンは後で直せないので慎重に

キースイッチを半田した後ではフロントパネルがはまっているで半田面にアクセスできなくなります。私は一箇所半田が不十分だったようで、うまくいきませんでした。ジャンパで逃げることができましたが、ジャンパで対応できる場所ばかりじゃないと思うので慎重に。

3.5mm4極コネクタはしっかりつくように

Foobarでは左右キーボードの接続に3.5mmの4極プラグを使います。コネクタは表面実装になるのでここが物理的に弱いです。
私はやっぱり半田が不十分でプラグを刺したときにコネクタを剥してしまいました。しかも、パターンも一緒に剥してしまいました!(> <)
ここもジャンパでことなきを得ましたがジャンパがたくさんピョンピョンと飛んでいるのは悲しいので、はじめからしっかり留めてね!

ファームの書き込み時にはリセットする

ファームはGithubにあります。
書きこむためのプログラム(dfu-programmer, avrdude, avr-gcc)をインストールしておきます。わたしはmacなのでhomebrewでインストールできました。
左右のそれぞれのマイコンに対してUSBで接続してプログラムを書きこみます。

$ make eeprom-left
$ make program

$ make eeprom-right
$ make program

このときにそれぞれの書きこみプログラムで3秒ほどスリープするタイミングがあります。そのタイミングで基盤に表面実装したタクトスイッチを押してリセットしてください。
マイコンのプログラム書き込みの為のUSBデバイスはリセットした直後にしかアクセスできないらしいです。

また、デバイスファイルのファイル名が違う場合もあります(macでは違っていました)。そういう場合はCOM_PORTという変数で指定してあげます。わたしの場合は以下のようにしました。

$ make COM_PORT=/dev/tty.usbmodem1431 program

さいごに

苦労の末、無事にわたしのはじめての自作キーボードは動きました。Foobarはキーの数が30しかないので、複数のキーの組み合わせで足りないキーを補います。 そして、それは個人によって使い勝手が分れるところでしょう。自分にとって使いやすいキーアサインを探す旅のはじまりです。 こういったカスタマイズも自作キーボードの魅力なんじゃないかと思います。

レトリバでは毎週レトリバセミナーという社内の発表会のようなものをやっています。一部のセミナーはYoutubeで公開されます。自作キーボードの話も登場すると思いますのでどうぞご覧ください。

レトリバでは自作キーボード仲間を募集しています。 こんなことをしていますが、レトリバは自然言語処理や機械学習といった技術で製品開発している所謂AIをやってる会社です。自作キーボード作りはあくまで趣味ですが、こんな楽しい仲間と働きたいと思ったかたは是非ご応募ください。

株式会社レトリバの採用/求人一覧 - Wantedly


2017-12-18

転職しました。

この記事はユビレジ Advent Calendar 2017の記事として投稿してます。

1ヶ月半ほど過ぎてしまいましたが、転職しましたのでご報告します。
前職はユビレジというiPadのPOSレジを作って運用している会社だったのですが、 マネジメントが比重が大きくなってきてしまったことと、 新しい技術にチャレンジしたいなという思いもあり転職することを決意しました。

新しい職場は、レトリバというコールセンター向けのソリューションを提供している会社です。
レトリバはPreferred Infrastractureからスピンオフした会社で検索エンジンであるSedueとそれに関連する事業を引き継いでやっています。
技術的には自然言語処理と機械学習に強い会社で、私がやりたい新しいチャレンジというのも機械学習の分野なので、レトリバにジョインすることにしました。

事実としてはこんな感じです。あとは転職にまつわるもろもろのことを書こうかと思います。

エンジニアリングマネージャーという仕事

ユビレジにはもともとソフトウェアエンジニアとして採用されたわけですが、採用を手伝ったりしているうちにマネジメント的なことをやるようになっていきました。
どこの会社でもそうだと思いますが、エンジニアはマネジメントが苦手な人が多く、ちょっとでもそういうことが出来そうな人がいると任されていくということはあります。
私自身、マネジメントが得意というわけではないのですが、年の功もあってエンジニアのなかではまとめ役にまわることが多くなっていました。
こういう話は業界あるあるでよくある話です。35歳定年説なんかもこういう感じでマネジメントに行くということが多く、そういう話がでてくるんだろうと思います。
私自身は生涯現役のプログラマでいたいなと思っていまして、そういう意味では趣味でプログラムも書けていましたし、マネージャーと言っても100%マネジメントというわけではないのでコードを書く時間は多少はありましたのでそれ自体が大きな問題だったわけではなかったように思います。
ただ、仕事をしていく中でなかなかエンジニアとして活躍していくことができないというのは自分自身焦りがありました。 そんななかでエンジニアとしてやりたいことが出てきたというタイミングで転職するという選択になりました。

で、私の転職の経緯としてはよくある話としてまとめられるわけですが、そうやって貴重な人材が流出していく(私のことではありません。一般論としてです)ということを企業としてどうしたらよいのかということを少し考察しようと思います。

このはなしの背景としては

  • エンジニアのマネジメントはエンジニアでないと難しい
  • マネージャーは忙しい

ということがあると思います。
ひとつめは概ね同意できることだと思いますし、この話の前提としてエンジニアがマネージャーをするということでなければ成立しない話です。
もちろん、エンジニア以外がマネジメントをするというやりかたもあると思いますが、私はそういう事例で上手くいっている話を知りません。
ふたつめのマネージャーは忙しいという話は必ずしもそうとは言いきれないかもしれません。
実際、わたし自身もマネージメントとして何をしてきたかと聞かれると、これということを挙げることはうまくできません。
ただ、とにかくいろいろ細々したことが日々ふりかかってくるという感じで、まとまった何かをするという感じにはなりません。
これは私がマネジメントが上手くないということの表れでもあるので、マネジメントの上手いひとならばもうすこしなんとかするような気もします。
とはいえ、相手はエンジニアです。コードも書きたいし、マネジメントはできればしたくないという人間にどうにかマネジメントをしてもらうしかありません。
マネジメントと一口に言っても、いろいろな要素があります。
チームビルディングや人にまつわる問題の解決など、あるいはもっと事務的なこと。予算を決めたり、チームの外部への報告。などなど書ききれないくらいいろいろな要素を複合的に扱わなければなりません。
なので一人の人間がマネジメントを担うことになれば、コードも書くなんてことはどんどん優先度が下っていくことでしょう。
逆に言うといろいろな要素があるので、役割を分担したり、チーム全体で問題を解決していくということもできるはずです。(私もそのようにしようと努めてはいましたが、先に書いたとおり他の要因もあって転職を決意した次第です。) マネジメント問題で人材を失いたくなければ、マネジメントの負担を一人に集中させてはいけないのではないかと思います。

機械学習のおしごと

機械学習をやりたくて転職したと言っても、レトリバでは機械学習そのものを仕事としてやるかどうかわわかりません。
面接のときにもそういう話はでてました。
レトリバではエンジニアとリサーチャーは職務が分れています。つまり機械学習の本筋のところはリサーチャーが担うことになっています。
なので目指すならばリサーチャーとしての採用を目指すべきだったかもしれません。
しかし、私自身は機械学習に関してはまったくの素人です。いきなりリサーチャーとして成果を出していくということは難しいことだと思います。
とはいえレトリバは機械学習を技術の柱にもつ企業ですので、その中で働くことは自分の今後のキャリアにとって良いことだと判断してレトリバにエンジニアとして入社することを決めました。

私はここ最近のAI・機械学習・ディープラーニングのバブル的な盛り上りは一時的なブームで終るとは思っていません。
むしろ、この周辺の技術はコモディティ化が進んでおり、あたりまえのようにディープラーニングをつかって様々な問題を解決することになっていくでしょう。 (これはディープラーニングが万能だと言っているわけではありません。ただ、これまで解決できなかった問題の中にディープラーニングで解決できることがあるということです。)
そして、ディープラーニングが実用として使われるようになれば、その周辺の技術も重要になってきます。
特にデータ処理は重要でディープラーニングは多くの学習データを必要とします。いままで以上にデータの重要性が増すことは間違いないでしょう。
そういうわけで、生存戦略としてもこの分野にベットしていくのはありだと思っていますし、なにより自分自身この分野には興味があるところなのでよい転職ができかなと思います。

さいごに

よく聞かれることなので最後に、どこでレトリバを知って、なぜレトリバを選んだかということを書きます。
なぜということに関しては上に書いたとおりなのですが、その中でもレトリバを選んだというのは、 『「深層学習による自然言語処理」読書会』という勉強会がレトリバで行なわれていてそれに参加したことがきっかけでした。
ちょうど他の企業からのスカウトなどをきっかけにして転職活動が本格化したなかでそのような出会いがあって、最終的にレトリバを選択したという次第です。
勉強会といえば、第2弾として『放送大学テキスト「自然言語処理(著:黒橋教授)」読書会』という勉強会を行っています。前回とは違い自然言語処理のもっとベーシックなところを学んでいきます。自然言語処理にご興味のあるかたは是非ご参加ください。


2017-10-10

技術書典3に出展します。

技術書典3に出展します。

「Pragmatic Opal」という本を書いています。
2015年から3年間、RubyKaigiに登壇してきました。いずれもOpalの話をさせていただきました。
Opalをつかった趣味の開発はRubyKaigiで登壇するためでKaigi駆動開発でした。
正直言ってOpalは実用的に使えるものではないと思っていました。 いまでもプロダクションでつかうにはちょっと厳しいんじゃないかなと思っています。
しかし、3年間Opal関連でいろいろ開発してきて、実はOpal結構やるじゃんって思っています。
そして、もっと実用的になるようにOpalのツールを開発してきました。
「Pragmatic Opal」はそんな3年間の集大成として書いています。
この本を読んでもらって、Opalやるじゃんってのをもっといろんな人に知ってもらえたらいいなと思っています。

う05で「みさきとミギー」というサークル名ででています。
よかったら遊びにきてくださいね。

P.S. 実はまだ原稿終っていません。落さないようがんばってますのでよろしくお願いします。


2017-09-10

RubyKaigi2017で登壇します。

今年で3回目となったRubyKaigiでの登壇です。
今年もOpalネタでいきます。
そろそろネタとしてでなく実用的な話としてやっていきたいのですが、今年はさらにネタ度が上っています。

「dRuby on Browser」

というタイトルです。
BrowserでdRubyしちゃおうというちょっとやばめのやつです。

私がdRubyを知ったのは、RubyKaigi2007のときです。ちょうど10年前の出来事ですね。
それ以前には私はCORBAをつかった分散オブジェクトのシステムに携わっていたりして、それなりに分散オブジェクトに関心がありました。
CORBAの複雑な分散オブジェクトに比べると、dRubyのシンプルさは衝撃的でした。

そんなわけで、dRubyです。
去年は「Isomorphic Web Programming in Ruby」という話をしました。
懇親会のときに関さんとサーバーサイドとクライアントサイドで透過的にオブジェクトを扱えるという考えがdRubyに近いですね。 なんていう話をしたりしました。
あー。なんかそれいいな。dRubyをOpalに実装できたら面白そうだなって思っていました。
また、クライアントがリッチなWebアプリケーションを本気で作ろうとすると、どうしてもWebSocketつかいたいなって場面がでてきます。
私がこれまで作ってきたOpalでWebアプリケーションを作るための取り組みのなかでWebSocketはすっぽり抜けているんですよ。
そこにdRubyを使うとなんか面白いんじゃないかなと思って作ってみました。
応用としては、Abstractにも書いたとおり、共同編集のアプリケーションなどです。
サーバーサイドのオブジェクトを共有できるのでこれうまくいくんじゃないかなって思ってます。

で、ここからがこのトークのみどころなんですが、実はまだ実装ができていません!
というか、大事な部分で実装が足りていないことが分りました。
そういうわけで、当日までに実装が完了するのかというのがこのトークのみどころになってしまいました。乞ご期待です。

あと、いまのところ出来上がっているところまでスライド公開しています。
スライド自体はそれほど変わらないと思うけど、まだちょっと変更が必要かもしれません。あとは当日のおたのしみということで。

https://youchan.github.io/RubyKaigi2017

P.S. ここ数年、RubyKaigiの関さんのトークがdRubyだったので、今年はダブルエントリーか!と思ったら違ってましたね。残念…


2017-08-19

RejectKaigiでRejectKaigiというトークをしました

何を言っているか分らないと思いますが、そのままです。
RejectKaigiというCFPをRubyKaigiに出したらRejectされたんだけど、どうやらRejectKaigiはSpeeeさん主催で行なわれるらしいということで、

という感じでトークすることになりました。

とはいえ、私がやろうと思っていたことはRejectKaigiそのものなわけで、RejectKaigiで話すことは何もない!!! このジレンマを自己言及というテーマで昇華しようということで今回のトークになりました。スライドはこちら

自己言及ということで3つのお話しをしました。

  1. RejectKaigiについて
  2. Ruby(というかプログラミング)の自己言及
  3. 私自身の話

RejectKaigiについては、はじめてのRejectKaigiという話をしました。私の知るかぎり、2007年のRubyKaigiのときははじめてのRejectKaigiだったと思います。
このとき私は速報ロガーを担当していて、RejectKaigiについてもログを書いていました。
私にとってもはじめてのRubyKaigiでRubyのコミュニティのすばらしさを始めて知った思い出深いRubyKaigiでした。

プログラミングにおける自己言及ということで、Quineの話をしました。もうこれはmameさんの独壇場なのでパクリでしかないのですが、「やってみた」ということで話をさせていただきました。
RejectKaigiというアスキーアートを出力するというよくあるタイプのQuineですが、Quineのなかに任意のコード(ホワイトスペースをすべて削除しても成立するという条件がつきます)を埋めこめるということで、ここにdRubyのサーバーとして機能するようなコードを埋めこんで自分の話に繋げるということをしました。
コードはこちら

3つめは自分自身にたいする自己言及ということで、過去2回のRubyKaigiでのトークの話と今年のRubyKaigiでするトークの話ということで宣伝をしました。

最後におまけとして、スライドはGibierという自作のツールで作ってますよということで、スライドも自己言及して終りました。

わたしのトークはそんな感じでしたが、他の方々のトークが皆すばらしく知見が沢山ありました。
Fablicのtommyさんという方がまとめていますのでそちらもぜひ読んでみてください。(http://in.fablic.co.jp/entry/2017/08/19/220645)


2017-07-17

GitHub Pagesにスライドを公開できるプレゼンツールを作りました

Gibierというプレゼンツールを作りました。
作りましたというか、以前からhyaslideという名前で開発していたものを名前を変更して、 いくつかの機能追加をしてリリースしました。
Gibierという名前はこのツールがうさぎとカメの追い掛けっこでおなじみのRabbitにインスパイアされていて、 hyaslideとい名前が適当に付けた名前だったのでいい名前ないかなと言っていてたら、koicさんに「じゃあジビエじゃないですか。」 と言われたのでつけました。
とても挑戦的で良い名前だなって思っています。

今回の機能追加での目玉機能はGitHub Pagesにスライドを公開することができることです。
発表当日まではローカルでサーバーを起動しておいて編集したり発表したりして、 終ったらGitHubにスライドプロジェクトごとpushしてGigHub Pagesにスライドを公開することができます。

使いかたはとっても簡単

まず、gemを使ってインストールしてね。

$ gem install gibier

スライドプロジェクトを作ります。

$ gibier new <slide_name>

実はサンプルスライドもできるので、それを参考に編集してね。

最後はパブリッシュ

$ gibier ghpages

ってするとdocsディレクトリが作られるから、それをGibHub Pagesとして公開するだけ

GitHub Pagesについては
https://pages.github.com/
をみてね


2016-10-29

RubyConf Taiwan 2016 に登壇します。

https://2016.rubyconf.tw/

トークの内容はRubyKaigi 2016のものと同じものの英語版になります。 RubyKaigiのときよりは長めのセッションに申しこんだので、デモがもうちょっとちゃんと見せられると思います。


2016-09-26

OSS Gateワークショップに参加しました。

https://oss-gate.doorkeeper.jp/events/46275

「OSSの開発に参加する」を実際に体験するワークショップです。

ということで、実際に体験してきました。
わたしはこれまでhyaliteだったり、先日公開したmeniliteだったりと、 いくつか自分のOSSのソフトウェアを公開してきました。
ところが、これらは一人で作ってきたソフトウェアでOSSの開発に参加しているという感覚があまりありませんでした。 (もちろん、わたしが作ってきたこれらのソフトウェアの開発に誰かが参加してくれたらとてもうれしいです。)
それに、わたしの開発しているソフトウェアがOpalを利用したものなので、Opalをもっとよくしていく活動には興味がありました。
そういうわけで、Opalの開発に参加するファーストステップを踏むために、このワークショップに参加することにしました。

結果としては大正解で、いくつかのPull Requestを投げてマージしてもらうことができました。
わたしのようにOSSの開発に興味があって、何から始めたらよいか分らないという人はぜひ参加したらよいと思います。

今日はOSS Gateワークショップに参加して得られた学びについていくつか書こうと思います。

最初はごく簡単なことから

始めからコードを直してPull Requestするということができると良いのですが、ちょうど良いサイズのものがないとなかなかハードルが高く感じます。
OSS Gateではドキュメントの修正なども開発者にとってとてもありがたい貢献だということで、ドキュメントなどから入るのを勧められました。
実際にやってみると、確かに英語で説明しなければならないとか、コードの修正だと状況に応じて考えることがあるとか、複数のハードルがあるのが一気に下ります。 つまり、英語で説明するというひとつのハードルに集中することができるのです。 最初の一歩としてはとても良いやりかただと思いました。

このワークショップの進めかたとしては、まず、ワークショップのリポジトリにissueを立てて、そこに作業ログを残しながら進めていきます。

わたしが立てた作業ログのissueはこれです。 https://github.com/oss-gate/workshop/issues/118

ワークショップでは、開発者としてではなくユーザーの立場になって対象のソフトウェアをインストールしたり、チュートリアルをしてみたりして、課題を見つけるというやりかたをしました。
このユーザーの立場になってというのが重要で、例えばインストールでつまずいたり、チュートリアルで分りにくことがあったりということを見つけていきます。
初心者がつまづく場所を直していって次にそこを通る人がつまづかないようにすることは、そのソフトウェアをより良くしていくひとつの方法です。
また作業ログを取りながら進めていくというやり方は、あとでやるべきことはログを見ればよくなるので作業に集中することができ、とても優れたやりかただと思いました。

伝えたいことはなに?

課題がみつかったところで、ドキュメントを直してPull Requestを出します。
ここで問題となるのが英語です。 でも、本当に英語が問題なのでしょうか?
まず、伝えたいことが何なのか?簡潔な日本語で書いてみる。なるべく箇条書きのように書くということを教えていただきました。
伝えたいことが何なのか、日本語でも簡潔に書こうとすると結構難しいものです。 逆に、簡潔な日本語になっていれば、英語に直すのも簡単になります。

でも英語が課題 > <

それでもやっぱり英語が課題だなというのはこのワークショップを通して思いました。
こればかりは英語の習得をがんばるしかないですね。
でもOSSの活動を通して英語を学ぶというのもひとつのやり方だと思います。 英語も楽しく学べたほうがよいですからね。

さいごに

こうしてめでたく、ワークショップ中に2つのPull Requestを出すことができました。 (2つとも翌日にはサクっとマージされていました。)
ワークショップでは他にもここに書ききれない学びとすばらしい体験がありました。
メンターの人たちもとても親身で手厚くサポートしてくれます。
OSSの開発に興味のある人はぜひ参加するとよいですよ!


2016-09-23

スライドアプリをリリースしました。

Hyaslide

以前から公開されてはいるのですが、誰でも使える状態にはなっていなかったので、整理してリリースしました。
使い方は REAME.md にあるとおりです。インストールしたら、hyaslideコマンドでプロジェクトを作成して、rackup で起動するだけです。

サンプルのスライドがありますが、あまりにシンプルすぎるので私のRubyKaigi2016のスライドなどを参考にしてもらえると良いかと思います。
以下のリポジトリにいくつか最近の発表のスライドがあります。
https://github.com/youchan/slides


2016-09-12

うちに帰るまでがRubyKaigiです。

というわけでわたしのRubyKaigiはまだ終っていません!

帰るの失敗して泣きそうになりながら、京都駅あたりをうろうろしていたところ、 @a_matsudaさんという方からごはんでもたべましょうというお誘いをいただきました。
で、いまどこなんですー?って聞いたところ

とのことなので、下山するまでしばらくまんが喫茶で休憩しながら待ちつつ、このブログを書いています。

まあ、そういうわけなので特に書きたいこともないので、今後のRubyKaigiの後処理について備忘録を書いておこうかと思います。

  • meniliteのドキュメントをまとめる。まったく使いかたが分らないと思うので、簡単なREADMEと今回デモした内容をどこかにまとめておこうと思います。
  • 英語のconferenceに応募する。どことは言いませんが応募するつもりです。通らなければ他のとこに。とにかくどこかで英語で発表したいと思ってます。

意外と早く下山できたそうなので、まだありそうだけどこのへんで…


2016-09-09

RubyKaigiのスライド公開しました。

昨日お伝えしたとおり、スライドを公開しました。

http://rubykaigi.youchan.org

eventmachineがビルドできない問題は、
https://github.com/eventmachine/eventmachine/issues/517#issuecomment-56255401
これで解決
なんとコンパイラ等がインストールされていないだけでした…(おはずかしい> <)

今回の発表では、ライブコーディングをしました。
ライブコーディングの臨場感はスライドでは伝わらないのが残念です。 例年どおりであれば近いうちにビデオが公開されると思いますので、そちらを見てもらえばよいと思います。

2日目の今日は発表のプレッシャーからも開放されたのでKaigiを楽しんでおります。ではまた


2016-09-08

RubyKaigiで発表してきました。

京都に来ています。もちろんRubyKaigiに参加するためにです。
初日の今日、「Isomorphic web programming in Ruby」という話をしました。
相変わらずOpal大好きっこです。
OpalでIsomorphic programmingするgem、meniliteを作りました。
いや、作りましたではなく作ってますですね。
hyaliteにつづいてmeniliteです。鉱物シリーズです。
今日の発表のことについていろいろ書きたいのですが、とりあえずまだKaigiがつづいているので後日かきます。
とりいぞぎ伝えたいのは、meniliteについてこのブログで今後書いていくよーってことと
今日の発表の資料は近いうちに公開しますということです。
(公開できないのはamazon linuxでeventmachineがビルドできなくてスライドアプリがサーバーで動いていないからです…)


2016-03-30

React.rb

cuba-reactというのをRubyFlowで見かけたので、どんなものか覗いてみました。
CubaというWeb frameworkにreactをintegrateするものということのようで、 これ自体はCubaに合わせてtemplateを生成するもののようですが、生成されるtemplateに驚きがありました。

react.rb

class HelloWorld
    include React::Component
    def render
        h1 {"Hello, World!"}
    end
end

Document.ready? do
    React.render(React.create_element(HelloWorld), Element["#content"])
end

これはまるでHyaliteのサンプルコードと似ています。
どういうことか調べてみると、どうやらReact.rbというものを使っているのでした。

React.rbはOpalで動くReact.jsのラッパーでした。サイトもしっかりあってまじめに作られています。
first commitは

zetachang committed on 7 Feb 2015

ということで1年くらい前から開発していたようです。

似たようなプロダクトがこの世に存在していたのに、車輪の再発明をしてしまったのは私のsurvey力の至らなさです。
とはいえ、ラッパーではReact.js自体の実装に縛られます。HyaliteはあくまでReact.jsを参考にした独自の実装です(実はReact.jsからずいぶんと拝借していますが…)
今後いくらでも独自の路線に進むことができるので気をとりなおして次のことを考えていきたいです。


2016-03-29

Kernel#procのはなし

ちょっと前の話なんですが、最近ブログ書けていないのでAsakusa.rbで話題になったちょっと意外なKernel#procのはなしを書きます。

Kernel#procというと、こんな風に書くとProcオブジェクトが生成されてProc.newとか書かなくてよいよねくらいの便利メソッドです。

proc do
  hogehoge
end

ところでみなさん、ブロック付きで呼び出されたメソッドでブロックをProcとして使いたいときはどうしているでしょうか?

def method(&block)
  hogehoge(&block) # 例えば次のメソッドにそのまま引き渡す
end

こんな風にブロック引数を定義しておいて使うのではないでしょうか。
実際にこの話題が出たときもとあるソースコードを読んでいるときにこのようなコードがありました。
私がブロック引数を使わなくても書けるということを言いだしたのがことの発端です。

Rubyのブロック引数は必ず最後に書かなければならず、yieldするだけなら省略することができます。 block_given?なんてメソッドもありますし、ブロック引数なんて書かない場合がほとんどなのではないでしょうか。
ところがこのケースにはブロック引数を書かなければなりません。
どうしてもブロック引数を書きたくない場合にはこんな風に書くこともできます。

def method
  hogehoge &proc { yield } # yieldの呼び出しをProcでくるみます
end

おや、これはProc.newするので遅くなりそうですね。実際にベンチマークを取ると倍くらい遅いようです。
そこで登場するのが、Kernel#procのブロックなしの呼び出しです。
こんな風に書けます。

def method
  hogehoge &proc
end

めっちゃ簡潔です。ベンチマークもブロック引数の場合と変りないです。
なんとこの用法、その場にいた誰もが知らないというのです。しかしリファレンスマニュアルのKernel#procの項をみると次のように書かれています。

与えられたブロックから手続きオブジェクト (Proc のインスタンス) を生成して返します。Proc.new に近い働きをします。 ブロックが指定されなければ、呼び出し元のメソッドで指定されたブロック を手続きオブジェクトとして返します。呼び出し元のメソッドがブロックなし で呼ばれると ArgumentError 例外が発生します。

そして、こんな風にも…

ただし、ブロックを指定しない呼び出しは推奨されていません。呼び出し元のメソッドで指定されたブロック を得たい場合は明示的に & 引数でうけるべきです。


2016-03-13

Keith Emerson

Keith Emersonが亡くなったそうです。

http://www.synthtopia.com/content/2016/03/11/keith-emerson-dead-at-71/

Programming hero をロックスターなんて呼ぶ風潮がありますが、Keith Emersonは私にとって本当の意味でロックスターでした。
今年はDevid Bowieが亡くなったし、Glenn Freyも亡くなりました。ロックスターたちが相次いで亡くなる年ですね。
去年Apple Musicなどの定額の音楽配信サービスが始まったり、音楽シーンに大きな転換が起こっています。 時代の変わっていくのを感じます。


2016-03-01

scrutinizerをつかってみる

https://scrutinizer-ci.com/

クソコードの測り方というスライドにあったので試してみた。 (クソコードという呼び方は好きじゃないけど)
GitHubアカウントでサインインして、測定したいリポジトリを選択するだけ。プライベートリポジトリだとアクセス許可したりする必要がありそうだけど、 パブリックリポジトリならすぐ試すことができる。
言語はPHP/Python/Rubyが選べる。対応言語は少ないけど、今後、増やしていくのだろう。

https://scrutinizer-ci.com/g/youchan/hyalite/?branch=master

2箇所ほどクリティカルがあるけど、全体的にはまあまあのスコアだったので意外だった。
まずはクリティカルをなくすことから始めよう。

そうそう、今日はAsakusa.rbに行ってきた。Asakusa.rbは基本的に誰かと話をするか、もくもくと作業するかという感じで過している。
今日わたしはHyaliteのテストを書いたりしていた。
リファクタリングをしていこうかと思っているのだけど、どこから手をつけたらよいか迷っていたところ、こういうサービスがあったので、ちょっとヒントになった。
メトリクスの測定とかいつもはツールの導入とかめんどうであまり積極的にやらなかったけど、これは簡単に導入できるので、なかなか良いサービスだと思った。