Studio3104::BLOG.new

uninitialized constant Studio3104 (NameError)

vue.js でチェックボックスによってセレクトボックスの enabled/disabled を切り替える

タイトル通りの挙動を、このエントリを書いている現在で javascript がまったく得意ではない自分が jquery で書くとこんな感じになります。
きっともっとまともな書き方があるんでしょうけども、非常に冗長な感じですね。

vue.js で書いてみた

めっちゃスッキリした。
el で指定したセレクタの配下がスコープになるので、上記の jquery のように挙動ごとにセレクタを指定しなくて良くて(きっともっとまともな書き方があるんでしょうけども)スッキリ書けて良い。

vue.js でチェックボックスによって表示/非表示を切り替える

タイトル通りの挙動を、このエントリを書いている現在で javascript がまったく得意ではない自分が jquery で書くとこんな感じになります。
きっともっとまともな書き方があるんでしょうけども、非常に冗長な感じですね。

vue.js で書いてみた

めっちゃスッキリした。
el で指定したセレクタの配下がスコープになるので、上記の jquery のように挙動ごとにセレクタを指定しなくて良くて(きっともっとまともな書き方があるんでしょうけども)スッキリ書けて良い。

tmux 1.9 でペイン分割時にカレントディレクトリを維持

tmux 1.8 (それ以前のバージョンは知らない) では、ペイン分割時に現在フォーカスのあるペインのカレントディレクトリで新しいペインを作ってくれたが、どうやら 1.9 からはそうではなくなった模様。

だいぶ不便なので、.tmux.conf をこのようにした。
( | や - での分割はデフォルトではないので注意です )

# ペインを縦分割
unbind %
bind | split-window -h -c "#{pane_current_path}"
if-shell '[[ "`tmux -V`" =~ 1\.8 ]]' 'bind | split-window -h'

# ペインを横分割
unbind '"'
bind - split-window -v -c "#{pane_current_path}"
if-shell '[[ "`tmux -V`" =~ 1\.8 ]]' 'bind - split-window -v'

split-window コマンドのオプション -c#{pane_current_path} を渡してあげるようにする。
1.8 でこの設定を食わすと、逆にカレントディレクトリを維持してくれなくなるので、if-shell でバージョンを確認して -c 以降を渡さないようにしている。

Sinatra で Controller を分割したくなったら Rack::URLMap を使うとよさそう

こういう感じのアプリケーションがあったとします。

で、この例だとまったくファットじゃないんだけど、Controller がファットになってきてしまった場合に、いい感じに分割したくなることもありますよね。
ということでとりあえずこうしてみた。

各クラスが Sinatra::Base を継承するではなくて、Base を設けてそれを継承するようにしているのは、各クラス内でそれぞれ before を書きたくなかったからです。
が、このように書いてしまうと、リクエストパスによっては 1 回のリクエスト中に before 内の処理が複数回実行されてしまいます。(実際に before に適当に p 123 とか書いて起動して、アクセスしてみるとわかる)

それだと最悪なので、最終的にこうした。

ルーティングを config.ru に書きたくなかったので、定数化して呼び出すようにしています。

参考

Sinatra Pattern 20130415

[Ruby] method の Thread をたてるときに method に引数を渡す

普通にメソッドをスレッド化するとこうなる

#!/usr/bin/env ruby
require 'thread'

def foo
  num = 0
  loop do
    sleep 1
    num += 1
    p num
  end
end

t = Thread.new(&method(:foo))
t.join

引数を取るメソッドをスレッド化したい場合

これは Syntax error

#!/usr/bin/env ruby
require 'thread'

def foo(num)
  loop do
    sleep 1
    num += 1
    p num
  end
end

t = Thread.new(&method(:foo), 0)
t.join
-:12: syntax error, unexpected ',', expecting ')'
t = Thread.new(&method(:foo), 0)
                             ^

shell returned 1

これは ArgumentError

#!/usr/bin/env ruby
require 'thread'

def foo(num)
  loop do
    sleep 1
    num += 1
    p num
  end
end

t = Thread.new(&method(:foo, 0))
t.join
-:12:in `method': wrong number of arguments (2 for 1) (ArgumentError)
  from -:12:in `<main>'

shell returned 1

これが正解

#!/usr/bin/env ruby
require 'thread'

def foo(num)
  loop do
    sleep 1
    num += 1
    p num
  end
end

t = Thread.new(0, &method(:foo))
t.join
とのことです

f:id:studio3104:20140911014653p:plain

YAPC::Asia 2014 Tokyo で 40 分の時間をいただいてお話させてもらった

「ブログを書くまでが YAPC::Asia」とのことですので、このエントリを以って僕の YAPC::Asia 2014 が終わってしまいます。

インフラエンジニアは死んだ

インフラエンジニア(狭義)は死んだ - YAPC::Asia Tokyo 2014

トークに応募したきっかけ

「声を上げない層をターゲットにしよう」ということを、トーク募集期間中に実行委員長の和田裕介さんがブログに書かれていました。

僕が2年連続でベストトーク賞をとれた訳 #yapcasia - ゆーすけべー日記

で、よく観察してみると、グレイトな ライブラリやサービスをつくっているハッカーは
「ただ口も声も大きいから」目立っているだけで、1,000人という規模の来場者からしたら
実はごく少数のマイノリティなんすよね。

ああ、なるほど。と思いました。
なんか、いわゆるそういう声の大きい人たちの評判、反応ばかり気にしてしまって、自分の意見を言いづらいみたいな感じに勝手に自分で決めつけてしてしまっていたのかもなぁ、と気付かされました。
「ああ、なんか勘違いしてたかも」と思わせてもらえた。ので、勇気をひねり出してトークに応募してみました。

話したこと

  • 自分は何を果たすべきか考える
  • 名称に縛られてしまうことで行動を起こさないと死ぬ
  • 必要になったときに出来る準備をしておく必要がある

ということを主張してきました。
僕自身、「インフラエンジニアだしプログラミングとか自分のすべきことの範疇の外のことだからするつもりもないし」と思っていた時期がありました。
しかし、それは誤っているのではないかという思いを持つようになり、紆余曲折を経て実際に今ではコードを書くことで解決できる問題に向き合って取り組む時間が多くなりました。
その課程の話をさせていただきました。

伝わりきらず残念だったこと

「なんかいいこと言ってたっぽいけど、結局は人の言葉の引用だよね」みたいなご意見もちらほらといただきました。
まぁ実際に発表内容にはそういう場面も少なくなく、真っ向から否定は出来ないのですが、そういう印象が真っ先に感想として出てきたということは少し残念でした。

実際に何か自分に取って刺さる内容の主張や意見に出会った時に、「刺さった」とか「いい話だった」と感想を持つことは多いと思います。
多くの場合はそこで終了してしまって、その先の自分に活かすための行いを伴うというところまでいかないのではないかなと。

僕の場合は、色々な方々の意見や教えを自分なりに咀嚼して解釈し、それを自分に活かして現在に至るというところがあります。
今回の話はその集大成という意識がありましたので、それをきちんと伝えられるような話し方が出来なくて非常に歯がゆい思いがございます。

なんかもっとこう、実例というか、もっと具体的にやってきたこととかをお話し出来れば良かったのかなぁと反省しております。
次に活かす。

意外と共感の声が聞こえてきた

嬉しいことに多くの共感の声もいただきました。
懇親会でもたくさんの方に声をかけていただき、トークの内容や境遇などについて大勢の方とお話させていただきました。

開発者のお祭だし、共感はあまり得られないだろうなーと思っていたので、同じような思いを持たれて共感してくださる方が意外と大勢参加されたいたんだなぁということに大変驚きました。
YAPC::Asia の幅の広さ、本当にすごい。

YAPC::Asia Ramen Challenge

これもまわってきて、次にまわしたし、これで本当の本当に僕の YAPC::Asia 2014 は終わったと言える。
数年ぶりに食ったなりたけ、すごくうまかったけど、食い終わった後に激しい胃もたれが襲ってきて老いを感じさせられてつらかった。

#yapcramen YAPC::Asia Ramen Challenge - @bayashi Diary

さいごに

今年で3回めの参加でした。本当に楽しかった。
運営スタッフの皆様、スピーカーの皆様、参加者の皆様、本当に素晴らしい場を提供してくださりありがとうございました。