手が震えたらBARに行こう

駄文を吐き出して、今日もなんとか、元気に生きていこうと思います。twitterアカウントは、@tabunmuri255です。よろしくです。

温泉・酒・同人誌 1万3000年にわたるもくもく温泉の謎

もくもく温泉というサークルの話

タイトルは適当につけました。(適当すぎる・・・。)

さて、この記事は、技術同人誌 Advent Calendar 2018の1日目の記事です。
そして、盛大に遅刻しました。すいません。ついカッとなって、登録したけど、難しかった。

もくもく温泉というサークルについてお話します。
このサークルは現状、技術書典とコミケットの2つに出ています。

f:id:kirin255:20181209223611p:plain
もくもく温泉(月く西31a)

もくもく温泉の次回日程

これいちばん大切なことなので、最初に書いておくんですが、もくもく温泉なるイベントは2〜3ヶ月に一回やっていて、次回は2019/01/12(土)から二泊三日でやる予定です。
mokumoku-onsen.connpass.com

できた経緯

2015年ぐらい
tabunmuri「フリースタイルなもくもく会やってるけど、いつも、もう少しやりたいぐらい!ぐらいで終わるんだよなぁ〜」
tabunmuri「そうだ!温泉でやればいいんだ!」
tabunmuri「そうすれば24時間、開発しまくれるぞ!!!」

_人人人人人人人人人人_
> もくもく温泉爆誕 <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

これぐらいのチョロい感じでできて、最初の1, 2回は普通の会ったことある人中心にやってみました。
そうしたら、まぁまぁうまくいって、だんだん、connpassにイベント立つようになって、今に至るという感じです。
現状、14回目の開催だけど、長く来たな〜というお気持ちです。

すごい。

課題感

ということを繰り返しているうちに、「やっぱり温泉フレンズ増やしていきたいよねぇ〜」という声が出てきた。
大まかな理由としては

  • 参加者増えたほうが大部屋とかかりやすいよね
  • 多種多様な参加者が来てくれたほうが、意見ほしい時とか、ありがたいよね
  • 参加者自身も交流をしていきたいよねという気持ちがあり、新しい人が入ってくれると嬉しい

というところ。
ということをふまえて、ついに、開発合宿の団体として、もくもく温泉というサークルが爆誕した。

本を作った

ということで、本を作った

気軽に作った。同時に助っ人のDTPスゴイできる尊師のK氏に迷惑をかけまくった。
けど、ここまでもってきてくれて本当にありがとうという気持ち。

ついに机の上に並んだ。
記憶が間違っていなければ、まだキンコーズの自動製本機能などは用いず、一冊ずつ真心を込めて製本していた。
会場で製本してる時に、一番製本してる人を工場長とよんでいた気がする。

そして、その結果他の人が「いいなー」とか、「行ってみたいなー」とか言ってくれるようになったので、やってよかったという充足感。
だんだん、このあたりから本を見て参加してみましたという人が増えてくれた。


そういった人でも気に入ってくれた人は、リピーターで参加してくれるようになってきたし、当初の課題感に貢献はできてきたのでよかったよかったという感じ。
めでたい〜〜。

特に何回か作っていく中で、合同サークルだからできることとして、温泉クロスレビューなる発明をした時は、天才過ぎて死ぬかと思った。


もくもく温泉は、温泉のslackがあるのですが、 https://mokumoku-onsen.herokuapp.com/ この中でみんな頼む〜とお願いしたらタイトなスケジュールにも関わらず、どうにかなる人はナイスな文章を書いてくれた。本当にありがたい。
聖人か!

そして、段々、もくもく温泉の参加者の人で、主催でも何でもないのに善意で手伝ってくれるようになったり

なんなら、宣伝も手伝ってくれるようになった。

この時期でようやく、「tabunmuriが主催してたもくもく温泉」がだんだん「みんなのもくもく温泉」にシフトしていく兆しが見えてきた。
常々、自分が爆散したら、多分続かないんだろうなぁ〜という思いはありつつ、でも好きな人の間でいい感じで回ってほしいし、自分が参加できない時期もあるので、団体で運営していきたいよねって気持ちは持っていた。

積極的に手伝ってくれる人も出てきて、いつも、ほんとに感謝しかない。

そして、なんなら、ついに例の記事にも乗った。(やったぜ)

毎回本を用意するのは大変だけど、少しずつだけど前進している感じ。

イベントの所感

コミケ

いつも、旅行とか評論のあたりで出してるけど、技術書典とかとは、普段縁が無さそうな人たちが見つけて買っていってくれる感じ。
大きく売れるわけではないけど、でも、過去の参加者や気になってるって人などがふら~っと来てくれて、とても楽しい。
あと、技術書典ほど忙しくない。いつもまったり進行。

技術書典

技術書典3は、友達のサークルに間借りしてた事もあって、「自分ら大手じゃないんで・・・」って、まったり進行だったんだけど、
技術書典4や、技術書典5からは、段々忙しくなってきた感じ。
特に、技術書典5でようやく気がついてしまったんだけど、多分、技術書典で開発合宿に関するサークルって多分ここしかなくて、超ブルーオーシャンじゃん!!!!って小躍りしてた。
ただ、別にブルーオーシャンだからといって、売上を追っていきたいみたいな意思はないし、このサークル活動はあくまで新しい仲間を増やす活動としてやっているので、あまり影響はなかった。なーむー。
このあたりで段々、本の内容自身も、開発合宿マニュアルのような立ち位置になってきて、買っていく人のニーズとしては、自分で開発合宿やりたい!とか、社内で参考にしたい!みたいな意図で買っていかれる人が多かった。

実際一番刺さった紹介としては、

  • 開発合宿で一番めんどくさいのは、「大部屋の有無」「ネット回線状態」「温泉」「交通の便」あたりで、これらをイチから調べると平気で1時間立っちゃうよ!
  • だったらこの本を買って、開発合宿を開いたほうがあなたの時給的に断然お得!!!
  • 買うしかない!!

と言った感じでした。
これは実際そうで、自分で調べる価値ってあんまりないと思うし、ノウハウはどんどんコピっていってほしいと思う。
なんなら、宿の方で開発合宿のニーズを理解して、プランを作ってくれるまでいくと本当にありがたい。

結論

  • もくもく温泉という開発合宿主体のサークルができました
  • 技術を布教するというよりかは、技術を共有する場を提供するサークル活動
  • いつでもウェルカムなので、気軽に来てくれ。

次回日程

mokumoku-onsen.connpass.com

ちなみにこのイベントページの文末にいままでの参加ブログとかあるから雰囲気知りたかったらそういうのも参考になるかもしれない。
f:id:kirin255:20181209232736p:plain

おまけ

実は、Tシャツを作ったりもしてみた。ちょっとたのしかった。
これは、

  • 温泉のグッズができて、その売上を学生さんとかの宿泊費に補填できるといいよね〜
  • 開発合宿どうせ、一日中カタカタやってるんだからどうせだったら着やすい服があってもいいんじゃない?

みたいな発想からできたものだけど、生地をすごくいいやつにしたので、大正解だった。
これはずっと着てられるいいやつ。


ただ、もう一回作りたいね!とは思いつつ、ハイパーTシャツクリエイターが温泉フレンズの中にいないのは、痛恨の極み。
Tシャツとか、グッズ作りたいフレンズがいたら気軽に声かけてほしい。
温泉一回分ぐらいは無料になるんじゃないかな…どうなのかな。

二日目の記事はkonosumiさんのこちら。
www.konosumi.net

ではまた今度〜。

勉強会を開くということ

先日、フリースタイルもくもく会で、LTしてきました。

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

今回は、暑いので昼間っから飲酒OKにして、もくもくするスタイルにしてみましたが、結構、みんな、お酒を買ってきて、楽しく作業をされていたように見えたので、自分としてはひとつこれはこれで、アリかなといったところです。

あ、ちなみに次回はこちらです。

http://freestyle-mokumoku.connpass.com/event/18689/

代替わり

さて、今まで主催だったのですが、今回で、代替わりとなる為、次回より、別の人にバトンタッチです。
そうなると、今後は、良くも悪くも、変化が生まれる事になるかと思うので、ぜひ、これを期にいろいろやってみてほしいと思います。
また、その際に、会社の方針も大切だけど、エンジニアやコミュニティにとって、どうあるべきが望ましいか、という事を考えて運営していってもらえると少し嬉しかったりします。
(自分は、あんまり、偉そうなこと言えないけど)

ということで、今回が僕の主催で最後ということで、「勉強会を開くということ」というテーマでLTを行いました。
スライドを共有するよりかはエントリにしたほうが良いかと思うので、下記に、しゃべりそびれた事を含め、まとめておきたいと思います。

勉強会を開くということ

勉強会を開くと、自分とその周りの人たちに利益があるので、積極的に開いていったほうが良いという話。

自分が勉強会に参加するようになってよかったこと

友達が増えた

友だちが増えるのは単純に嬉しいし、懇親会の時にぼっちじゃなくなる。(地味に嬉しい)

最新の技術にキャッチアップしやすくなった

会社の中だけにいると、新しい技術ややり方、トレンドなどを見る機会が減るかと思います。
これを、勉強会を通して「知る」ことが大切かと思います。
理解することはもちろん大切なのですが、引き出しを増やすという意味で、まずは「知っておく」という事は重要だと思います。
そうすれば、問題が起こった時に、別のやり方を検討するということも出来ますし、その引き出しの多さがエンジニアとしての「代替の効かない何か」になることもあります。

会社の常識が実は、世間の常識でないことに気がつく

「有給は消化しないことがあたりまえ」「CIといったらJenkins」、「お前ぐらいの技術力なら、給料はこれぐらいで当然だ!」
みたいな主張がよくされたりしますが、でも、その主張って、本当ですか?ということがよくあります。
言っている側は、自分の中のルールに基いて言っているかと思いますが、勉強会で話をしていると「実はそうではない」という反例を聞ける事があったりもします。
エンジニアとしては、多様な意見の中で、自分としてはどうするかという事が決められると幸せになれるんじゃないかと思います。

主催するようになってよかったこと

友達がもっと増えた

僕の場合は主催ということで、毎回懇親会に行く事が多く、結果、知り合いが増えるというサイクルが回っておりました。
結果、twitterで絡んでくれる人も増えたし、飲み友達も増えました。
また、自分主催の勉強会に来てくれた人が、また別の勉強会を開いている場合があって、そんな感じで友達の輪が広がっていくこともありました。
特に、知らない勉強会に行った時に、話しかけてくれることが会ったりすると、本当に嬉しい。
YAPCで話しかけてくれた方がいたり、本当にありがとうございました。

苦手な分野を助けてくれる人ができた

???「@tabunmuriさん、◯◯のキャッチアップ助っ人しましょうか?」
って言ってくれる人が出たりして、本当にありがたかったです。
ありがとうございました。
そして、これからもよろしくお願いします。

困った時に、会社紹介してくれる人が増えた

良かったらうち来ますか?という話をたまに頂いたりします。
本当にありがたいです。ありがとうございます。
というか、遊びに行かせてください。

LTの準備などを通して、知らない話を調べる機会ができた

普段、自分プロジェクトの問題を解決する為の方法をググることはありますが、それだけで終わってしまうことが多々あります。
ですが、LTやらねば、ということになると、なんとか形にしようとがんばってしまうんですね。
ということで、一応人前で話ができるぐらいにまとめる過程で、知識の整理がされる事が多いです。
これは、結果的に、自分のアウトプットにもつながりますので、すごく良かったです。

企業にとっての利益

会社の名前を良いニュアンスで知ってもらえる

勉強会自身が良いものであれば、ソーシャルメディアを通じて、拡散してくれる。

会を開きましたら、twitterハッシュタグでつぶやいてもらったり、LT資料を公開してもらったりすることで、エンジニアのグループの間で、その名前を段々浸透させていくことができます。
すると、会社に面接に来てくれたエンジニアに対して、少し良い印象を与えることができるかと思います。(少なくとも、「何やってるかわからない」、また、「そもそも、エンジニアがいるのかもわからない」といった状態は脱却できるのではないかと思います。)
この時の印象は、エージェントさんや会社紹介経由などで聞くよりも、よっぽど良いかと思います。

求職者がいれば、ダイレクトに話ができる(エージェントなどを通さなくても、それなりに人が集まってくれる)

その場で、話ができれば、その場でどんな問題と戦っているのかや、条件は?といった話がフランクにできてしまいます。
この中で、お互いにとって、良いなと思えば、採用してしまえばよいですし、そうでなければ、
お互いのためにも「合わないかもしれん、スマン」と言うのが良いかと思います。

最新の技術トレンドの潮流を肌で感じることができる

LTや、世間話の中で、「どんな技術を使っているか」や「知見」、「これはやるな」といった事という話を聞けるのは、最高だと思います。
特に同じ技術に関する話が多ければ多いほど、それは世の中のトレンドなんだなということがわかりますので、
なんとなくギョーカイの潮流がわかったりします。
例えば、「swift」とか、「aws」とか。。

自社のエンジニアを最新のトレンドにキャッチアップさせる良い機会を作るという意味でも、有用。

じゃあ、どんなふうに運営を行えばよいか

テーマは大切だけれども、あまり難しくすると、自社にその分野に明るい人がいないと出来ないといった理由で、
開催するのが厳しくなってしまうので、設定の仕方は工夫が必要だと思います。

特定の技術に明るいエンジニアがいる場合

<その技術、言語で勉強会を開くのが良いかと思います。>
→ 東京node学園スタイル

そんなでもないけど、まぁまぁわかる人がいる場合

<特定のテーマに則って、LTをしてもらう会をやるスタイル>
→ 表参道rbスタイル

なんにもないけど、でも、勉強会開きたいんです!!!

<テーマを決めて黙々と作業をして、最後LTをして終わる形式>
→ フリースタイルもくもく会スタイル

運営側の心構え

準備が大切(名札など)

会が良い感じに終われるかの半分は、準備にかかっているといっても言い過ぎではありません。
名札を作ったり、事前にLTのガイドラインのメールを送ったり、できることはきちんとやっておきましょう。

LTのガイドラインのメール

それと、ふと思い出したので、ここで、LTのガイドラインに関するメールの内容を晒しておきます。

                                                                                              • -

みなさま

お疲れ様です。
LTに関するTIPSです。

1,LTは制限時間が5分です。
5分過ぎてしまった場合、発表が強制的に打ち切りになってしまいます。
なので、内容はコンパクトにまとめたほうがよいかもしれません。
また、あまり多くの事言うよりかは、何か一つだけ伝えたほうがスッキリして終わることが多いような気がしますので、何を伝えるべきかというのは、大切なポイントかもしれません。

2,LTでは、スライドを用意しましょう。
何かしら映す物がない場合、ご本人によっぽどのコンテンツ力がないと、せっかくの魅力が伝えられないことが多いかと思います。

3,オチを作る
一生懸命しゃべったにも関わらず、内容がスベることがあります。
そして、残念ながら、弊社では、発表終了後に床がパカっと開くような設備はありませんので、ラスト一枚にオチとなるようなスライドを入れておくと、うまく終われます。

4,続きは飲み屋で
LTは「ちょっと続きが気になるな、もっと詳しく聞きたいな」といった状態で終われますと、その後の懇親会で、盛り上がったり、友達が増えたりします。
なので、あえて、いいところで、終えるというのも一つの方法かと思います。

5,後日発表資料は、スライドシェアにアップする
発表した内容は、webにあげておくと、今後良いことがあるかもしれません。
webにあげてくれたことを教えていただけましたら、コンパス上でも反映いたしますので、宜しくお願い致します。

ということで、ざっくり書いてみましたがいかがでしょうか。
また、わからないことなどありましたら、@tabunmuri255まで、連絡いただければ、お応えいたしますので、遠慮なくどうぞ。

                                                                                              • -

チョロさは大切

茶番は大切(知能指数下げていこう!!)

難しい話を、「うんうん」と唸って聞くのも良いですが、本質と関係ない所は、バカっぽくやったほうが結果、面白くなってるような気がします。
バカっぽくなるとか、ならないとかは、主催が先陣きって、知能指数を下げられるかにかかっているので、この意見に賛同された方は、「オーイエー!」と、「エンジョイ!」の2単語だけ使って、会の運営を続けていくと、どうにかなれると思いますので、ぜひチャレンジしてみるのは良いかと思います。
エンジョイ。

初心者の人には特に優しく!

勉強会の発展は、初心者の人をどれだけ、「発表してもいいかな、発表したい!」というフェーズまで持っていけるかにかかっているかと思います。
なので、初心者の人が困っていたら、積極的に、助っ人することで、一人でも出来る人を増やしていきましょう!
もちろん、困っていなくても、積極的に話しかけていきましょう。
世間話なので、「今日何やってるんですか?」とか、「◯◯をやられているというお話をされていらっしゃいましたが、△△って知ってます?」みたいな話をサラーっと降れば大丈夫です☆

感謝の気持と忘れずに

会の運営には、「会場を貸してくれた会社」、「参加してくれた方」、「LTをしてくれた方々」の助けが必要不可欠です。
なので、決して、「会を運営してやっているんだぞ。」という気持ちにならず、むしろ、俺が楽しいからそれだけで、OKみたいな気持ちで運営していくと幸せになれるかと思います。
そういうわけで、関係している方々には、すべからく、感謝する気持ちを持って、接しましょう。


いかがでしたでしょうか。
勢いで書いてしまったので、少しまとまりがない部分もありますが、勉強会をひらくのは自分自身の成長の為にも、とても良い事です。
(例え、それが、日本酒とつまみにまみれていようとも。。)

ただ、それとは別に、参加する人がいてこその勉強会ですので、コミュニティに関わっている人全員で幸せになっていこうぜという方針を大切にすると良いかと思います。

エンジョイ!

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

Library not loaded: /usr/local/lib/libmcrypt.4.dylib みたいな何かが出て、困った時

こんなのが出て、非常に困った。

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/opt/php55-mcrypt/mcrypt.so' - dlopen(/usr/local/opt/php55-mcrypt/mcrypt.so, 9): Library not loaded: /usr/local/lib/libmcrypt.4.dylib
Referenced from: /usr/local/opt/php55-mcrypt/mcrypt.so
Reason: image not found in Unknown on line 0

Warning: PHP Startup: Unable to load dynamic library '/usr/local/opt/php55-mcrypt/mcrypt.so' - dlopen(/usr/local/opt/php55-mcrypt/mcrypt.so, 9): Library not loaded: /usr/local/lib/libmcrypt.4.dylib
Referenced from: /usr/local/opt/php55-mcrypt/mcrypt.so
Reason: image not found in Unknown on line 0

ググったら、下記のissueが上がっていて解決策が提示されていた。

github.com

簡潔に言うと下記の3ステップを踏んで、上書きして解決せよとのことでした。
1,brew rm mcrypt
2,brew install mcrypt
3,brew link --overwrite mcrypt

Thank you @CWSpear

RubyOnRailsでAPIを作る時のサンプルをgithubに公開した

先日から、何度かAPI関連のエントリを書いてました。

Ruby On RailsでAPIサーバを作ってJSONを受け取る方法 - 手が震えたらBARに行こう
railsでjsonに、permitで要素チェックしたい時の方法 - 手が震えたらBARに行こう

で、もっと良いコード書いてほしいと思って、すっごいシンプルなAPIのサンプルを作ってみました。
(ただ、中身は、本当にRails始めたばっかりの方向けの内容です)

github.com

もともとは、社内でJmeterの使い方口座をしようと思ったんだけれども、GetしてよいAPIサービスはあったんだけれどもPostして良いAPIサービスで簡単なのが見つからなかったので、作ってみました。

もしも、これを通して、Get, Post, Patch, Deleteあたりを理解することにつながると嬉しい。

また、凄くミニマムな、ソースコードだけど、APIサーバ作るにあたって必要な下記の3つの要素は入っているので、これで、最低限の話はできるのではないかなーと思っています。

  • Restな考え
  • Resourceを使ったURL設計(また、URL制限)
  • 入力値のvalidation

あとは、TestとJmeterアサーションの話あたりもしたいんだけれども、それはまた、後々という形になりそうです。

よろしくお願い致します。

railsでjsonに、permitで要素チェックしたい時の方法

とりあえず、声を大にして言いたいのは
railsのscaffoldは案外、知見がいっぱいあるよ
(特に、初心者の方にとっては。)

ということで、最近、jmeterの使い方から、負荷計測の方法のさわりをお伝えすべく、いろいろ準備していたりします。

さて、今日はRailsのPermitメソッドについて改めて記録しておきたいと思います。
Railsでは、permitっていう要素をチェックする仕組みがあるのですが、これはぜひ有効活用していったほうが良さそうです。
(ちなみに、node.jsだと、json_schemeってので、対応しておりました。)

# Never trust parameters from the scary internet, only allow the white list through.
def user_params
  params.require(:user).permit(:name, :email, :password)
end

こういうやつね。
scaffoldすると、全自動でブッこんでくれてるみたいなんですけれども、この仕組超便利っぽいですね。
なぜなら、この1行で、

1, paramsの中には、userというattributeがあって、
2, 更にその中で許可しているのは、name, email, passwordという要素のみ

ということをチェックしてくれているからです。

うーん、この仕組み、可能であれば、jsonのやりとりしてる時でも使いたいな。。。
ただ、jsonのparamsの中に入ってる状態って、パースされてなくて、使えないんだよね。
そんな時はこんなかんじにするといいよっていうのを調べました。

# Never trust parameters from the scary internet, only allow the white list through.
def user_params
  # 下記のようにすることで、paramsで実行していたpermitと同様のことができる
  json_request = ActionController::Parameters.new(JSON.parse(request.body.read))
  json_request.permit(:name, :email, :password)
end

まぁ、なんといっても、大切なのは下記の1行

  json_request = ActionController::Parameters.new(JSON.parse(request.body.read))

ActionControllerとしてnewするとpermitが使えるらしい。
これで、更新してほしくないパラメータのロックとかができるようになります。
自前で、チェックをかけようとしてるのであれば、検討してみると良いかもしれません。

参考文献

stackoverflow.com

Ruby On RailsでAPIサーバを作ってJSONを受け取る方法

送信側

送信側はpostでbodyにまんま下記を乗っける
サンプル元 JSON Example

{
    "glossary": {
        "title": "example glossary",
        "GlossDiv": {
            "title": "S",
            "GlossList": {
                "GlossEntry": {
                    "ID": "SGML",
                    "SortAs": "SGML",
                    "GlossTerm": "Standard Generalized Markup Language",
                    "Acronym": "SGML",
                    "Abbrev": "ISO 8879:1986",
                    "GlossDef": {
                        "para": "A meta-markup language, used to create markup languages such as DocBook.",
                        "GlossSeeAlso": [
                            "GML",
                            "XML"
                        ]
                    },
                    "GlossSee": "markup"
                }
            }
        }
    }
}

Content-Typeは設定したほうがよいのは明らかだが、なくても、動く。

受信側

受信側は下記のようなコードを書く

class Api::ExamplesController < ApplicationController
  # この↓一文がないとCSRFチェックでこけるので、APIをやりとりしているControllerには必要
  skip_before_filter :verify_authenticity_token

  def create
    # 読み込み時に一度パースが必要
    json_request = JSON.parse(request.body.read)

    # パース後のデータを表示
    # p "json_request => #{json_request}"
    # p "#{json_request.to_hash}"

    # 各要素へのアクセス方法
    # p "glossary => #{json_request["glossary"]}"
    # p "glossary.title => #{json_request["glossary"]["title"]}"

    # この後、postされたデータをDBに突っ込むなり、必要な処理を記述してください。
    if !json_request.blank?
      personal = json_request
    else
      personal = {'status' => 500}
    end

    render :json => personal
  end
end

JSON::ParserError - A JSON text must at least contain two octets というエラーが出たら

それ、もしかして、request.body.readを2回呼んでおりませんでしょうか。
JSON « ツール工房 覚書
を見ると、どうしてももう一回呼びたい時は、request.body.rewindをやれとのこと。

JSON::ParserError - A JSON text must at least contain two octets!:

というエラーが出てしまいました。
これに悩まされたのですが、


request.body.read

ファイルポインタが最後にある状態で次のreadを呼んでしまっていたんですね。
rewindで戻してあげる必要があったわけです。

参考リンク
こちらのリンク先は非常に、お世話になりました。
ありがとうございました。
JSON « ツール工房 覚書


おわり。

表参道.rbで「第一回チキチキUNICORNチューニング」というLTしてきた

表題の通り

去る2015/06/04 都内某所にて下記のイベントが密かに開催されていたomotesandorb.connpass.com

最近、Railsをやっているということ&前日のAWS Summitで発表したい熱が高まっていた関係もあって申し込みたい。
だけど、LTネタがない。。。。

今からつくろう!!
そして、できたら申込をして、できなかったら
無かったことにしよう
という大変にゲスい保守的な作戦で参戦
飛び入りでLTしたので、受付の人のリストに入っていない等、ご迷惑をお掛けしてすみません。

発表資料はこちら

第一回チキチキUNICORNチューニング

www.slideshare.net

詳しくやりだすと穴だらけて、ヤバいんだけれども、会場の皆様が結構優しくてよかった。
特に面白かったといってくれた人がいて、「あ、俺、ここにいていいんだ」という安心感が生まれてよかった。
ただ、インフラよりの話は、少しターゲットに刺さってない感じがしていた。(だがやめない( ・`ω・´))
あと、友達の輪が広がりそうでよかった。

他の人の発表について

知らない知識ばかり、発表されていたので、とても実りがあった。
最後に、僕の備忘録のために、発表資料をまとめておきます。

所感

好意的なレスポンスが返ってきたので、発表してよかった。
次もネタがあれば発表したい。
ちなみに、LTの練習としてはこちらのイベントがオススメです。freestyle-mokumoku.connpass.com

大変ゆるい会で、LTはテクノロジーに限らず、何の話をしても大丈夫なので、気軽に参加すると良いかと思います。

あと、Port株式会社では人材を募集しております!!!
- railsエンジニア
- インフラエンジニア
- webデザイナ
などが募集中ですので、もしも興味があれば、お気軽に@tabunmuri255まで、連絡ください。

ホットエントリー入ってるぅぅぅぅぅ!!!

朝起きたら、はてなブックマークのホットエントリーに入っていたのでちょっと嬉しかった
f:id:kirin255:20150605150512p:plain

いいゾ~これ。イヤッホーイ!!!