手が震えたらBARに行こう

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

勉強会を開くということ

先日、フリースタイルもくもく会で、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

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

railsにtwitter-bootstrap-railsを導入するまで

なかなかうまく行かずにハマってしまった。
まず注意しなければいけないのが、gemが

twitter-bootstrap-rails

twitter-bootstrap3-rails

で2種類存在しているということ。
こいつをうっかり、取り違えて操作をしていると、事故る。
詳細については、下記の記事にちゃんと書いてあるので、それを読んでもらうとして
Rails4でサイト構築をする – Bootstrap導入編 | TechRacho


下記のコマンドで、CSSとかJSを作成する。

$rails generate bootstrap:install static

insert  app/assets/javascripts/application.js
create  app/assets/javascripts/bootstrap.js.coffee
create  app/assets/stylesheets/bootstrap_and_overrides.css
create  config/locales/en.bootstrap.yml
gsub  app/assets/stylesheets/application.css

そして、レイアウトを差し替え
※fluidと書いてあるのは、レスポンシブ用

$rails g bootstrap:layout <レイアウト名> fluid

create  app/views/layouts/entrance.html.slim

これで、railsを起動している場合は、一旦、ctrl + cで落としてから再起動すれば効いてるはず。
やったぜ。

参考になったページtechracho.bpsinc.jp

マジで助かった。ありがとうございました。

マルチデバイス時代のWebデザインガイドブック

マルチデバイス時代のWebデザインガイドブック