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のテストを書いたりしていた。
リファクタリングをしていこうかと思っているのだけど、どこから手をつけたらよいか迷っていたところ、こういうサービスがあったので、ちょっとヒントになった。
メトリクスの測定とかいつもはツールの導入とかめんどうであまり積極的にやらなかったけど、これは簡単に導入できるので、なかなか良いサービスだと思った。


2016-02-25

フロントエンドかけこみ寺にかけこんでみた

フロントエンドかけこみ寺@もくもく会というもくもくする会に参加してきました。
というか2回目の参加でした。フロントエンドかけこみ寺についてはmurokacoさんのブログを参照してください。
まあとにかくもくもく出来るのがよいですね。仕事外の開発に必要なのは時間と場所ですのでこういう場があるのはうれしいです。
そういうわけで今回はなにをもくもくしたかというと、Hyaliteのテストを書いていました。
RubyKaigi以来Hyaliteの開発がしばらく停滞していたのですが、そろそろ触りはじめようと思い、まずはテストを書きはじめました。
Opalのテストはopal-rspecというgemで書きます。testunit系のテスティングフレームワークはないようです。残念です。
opal-browserのDOMのテストを参考にテストを書いていきました。spec_helperに定義されているHtmlHelperをコピーしてきて使おうとしましたが上手く動きませんでした。(opal-specに非互換?)
とりあえず簡単なテストが動いたので、これからテストを増やしつつ完成度をあげていこうかと思います。


2016-02-23

React.js meetup #3 に参加してきた

React.js meetup #3に参加してきました。
Christoph Pojerさんjscodeshiftの話がメイン。 jscodeshiftはJavaScriptをパースしてASTの状態で変換したりできる、JavaScriptのソースコード変換のツールキット。 AST Explorerで使える。
これみて思ったのは昔々、MINAKAというツールがあって、JavaをやっぱりASTで操作することができるツールがあったんだけど、それと近い。 MINAKAは人類には早すぎたのか、使うのが難しそうという印象があって日の目を見ることはなかったようです。
jscodeshiftのほうはどうかというと、Chistoph氏自身がhttps://github.com/facebook/react/pull/6097 このプルリクエストをjscodeshiftを使って生成していました。(今日のトークのなかでプルリクエストをポストしていました)
これなら、いまどきのオープンソースプログラマなら使いこなせるような出来になっているんじゃないかなという印象を持ちました。
あと、たとえばOpalのソースコード生成部分もASTを作ってからコード生成するようにすれば柔軟になるんじゃないかなって思っています。(ひそかに今後のES6への対応どうするのか危惧しています)
meetupでは他には、GraphQLやRelay.jsなど最近のReact周辺のトピックに触れて面白いと思いました。

今回はただ参加したのではなく、LTもしてみました。内容はもちろんHyaliteについてです。
Ruby界隈と違ってアウェイ感満載でしたが、懇親会では何人かの方に声をかけてもらいました。
今後もフロントエンド界隈にはちょこちょこ顔だしてみようかと思いますが、所詮Rubyでフロントエンドなんて際物もいいとこなので、おかしなおばちゃんがいるなくらいに思ってもらえばよいかなと思います。


2016-01-24

RubyMotion もくもく会 in Tokyoを開催しました

1月21日(木)に第22回 RubyMotion もくもく会 in Tokyoを開催しました。
もともとは2012年ころから@satococoaさんが主催していたもので、私は第6回から参加していました。
2014年くらいに東京での開催がされなくなってしまい、ずっとさみしいなーと思っていました。 開催されなくなった理由は会場の都合などを含めて複合的な要因があったのですが、世間的にもRubyMotionが下火になってきたのかなという印象をもっていました。
とはいえ、このもくもく会は大阪では今でもコンスタントに開催されているので東京で中心的なひとたちがたまたますこし離れてしまっていただけなのかもしれません。

そんな状況の中、RubyKaigiでLaurentのトークが話題になったり、私自信はOpalの上でフレームワークを書いたりして、新ためて他の言語を開発言語とするプラットフォームでRubyで開発できることの良さを再認識したりして、私の中ではRubyMotionに対する興味がまた再燃してきていました。
今なら私の所属している株式会社ユビレジの会議室を借りることでまたもくもく会を開催できると思い復活を果すことが出来ました。

参加したメンバーは以前もくもく会をしていたころの参加メンバーが多く久しぶりに顔を合わせた懐かしさにちょっと同窓会的な趣がありました。
とはいえ始めて参加される方やユビレジのメンバーなども参加したりして新しい展開もありという感じでした。
(今回参加表明していたけど途中でRubyMotionが有料の製品だと知らずに申しこんでしまいました。ということでキャンセルになった方もいらっしゃいました。 実はRubyMotionは今はStarterという無料のプランもあるので、まずは無料で始めるということができます。)

今回は久しぶりの開催ということで皆、motion updateや再イントールなどをしていました。 また、みんなでRubyKaigiのLaurentのトークの動画を見たりして過ごしました。

今回は再開して始めてだったのでいろいろイレギュラーな感じになりましたが、今後も月1回の開催で続けていこうと思っています。
RubyMotionに興味のあるかたはぜひ参加してみてください。

次回は2月18日(木)に開催予定です。 http://rubymotionjp.connpass.com/event/25964/


2016-01-18

milligram.cssを使ってみた

'A minimalist CSS framework' ということで使ってみました。
ちょっと見た目が変ったでしょ?

もちろんresponsiveにもなっているので、スマホで見てもいいかんじです。

bootstrapがいろいろおせっかいというか、そこまでいらないんだけどresponsiveだったり、多少今風なデザインになってるといいなってときにこういうフレームワークはありがたい。


2016-01-17

imba

http://imba.io/home

Webのフロントエンドを書くための新しい言語だそうです。
ReactのJSXのようなものがJavaScriptではなく独自の言語に乗っている感じ。 実装もおそらくVirtual DOMを使っているのだと思う。
ReactのオルタナティブでJavaScriptを書かないというところはHyaliteと似ている。
文法的にはRubyとPythonにインスパイアされているらしく、ブロックをインデントで表すなど今風な言語だけど、JSX的な表現はReactから受け継いでいるので個人的にはあまり好きじゃないな…
でも、Reactの10倍早いそうなのでこういうアプローチも悪くないとは思う。


2016-01-02

このブログについて

新年を向かえて新しいブログを作ったのですが、勢いあまって作ったのですが、
まあもちろん適当に実装されています。し、機能も充分ではありません。
日付のファイル名をつけられたmarkdownファイルをredcarpetHTMLに変換してhamlに埋めこむだけのsinatraのアプリです。 ブログを更新しつつ、このブログシステムもちょっとづつ機能を充実させたいと思います。
そういうわけで今日もひとつ機能を追加しました。
RSSを出力します。http://blog.youchan.org/rss でRSSを購読することができるはずです。


2016-01-01

あけましておめでとうございます。

今年もよろしくおねがいします。
ということで、今年からブログを一新しました。自家製です。
一昨年に転職してJavaからRubyへ、Webプログラマに転職したわけですが、Webプログラマたるものブログくらい時前で作らないとね。ということで、自家製のブログシステムでブログを書くことにしました。
2015年を振り返ると、自分の立てた目標をわりと達成できていて大変よい年だったなと思っています。
達成できたことは、

  • Rails Girlsのオーガナイザーとして、Rails Girls Tokyo 5thを開催する。
  • 大江戸Ruby会議でトークする。
  • RubyKaigiでトークする。

などがありました。
今年はこの勢いに乗ってさらなる発展をしていきたいなと思い、初心を忘れないためにこのブログというか日記を書くことを決意しました。
去年は目標を達成するためにしたというよりも、宣言したことを無我夢中でやって、またそれ自体が楽しくて余計に夢中になってやっていたという感じでした。
そういうのって充実感があって楽しくてよい感じだなって思うので今年もその路線で行けたらなって思っています。
そういうわけで今年の抱負を新年に語っちゃおうかなということでこのエントリです。

新年の抱負

  • 今年もRubyKaigiでトークしたい。
  • 海外のカンファレンスでもトークしたい。
  • 英語でトークしたり、海外の開発者とやりとりしたい。

ということを目標に掲げたいと思います。
カンファレンスでトークすることを目標としていますが、イベント駆動開発で開発が進んだり、カンファレンスでスピーカーとして参加することによって、いろんな人と仲良くなったりして、話すことそのものよりはそれによってもたらされるシナジーが自分にとって良いものだったからそうしています。
また、そうなってくると英語というのが大きな壁になります。せっかく海外の開発者と仲良くなる機会があってもコミュニケーションがとれなければうまく行きません。このことはこれまでにもさんざ経験してきたことなので今年こそは前に進みたいと思っています。

そういうわけで、この日記では、開発記録だったり、英語の勉強記録だったりを書いておこうかと思います。 今年の終りに日記を読みかえして、また今年も良い年だったなって思えると良いなーって思っています。

2016年 元旦