WeeChat は IRC Bouncer にもなる
テキストベースの IRC クライアントとして有名な WeeChat ですが、IRC Bouncer としても使えることがわかり、使ってみたら大変によさそうであったので共有いたします。
旧環境
最近まではこんな感じで ZNC に IRC サーバに繋ぎっぱなしにさせて、クライアントが繋いできたときは設定された行数をプレイバックするみたいにして使っていた。
+--------------+ IRC +---------+ IRC +-------------+ | LimeChat(PC) | ---------> |+-------+| -----> | Company IRC | +--------------+ || ZNC || +-------------+ +------------------+ IRC |+-------+| IRC +----------+ | LimeChat(iPhone) | -----> | Server | -----> | freenode | +------------------+ +---------+ +----------+
これだとちょっとダルい問題があって、PC からだとネットワークが切れて再接続されるたびにバッファプレイバックするので、直近で nick 呼ばれてたりするといちいち LimeChat が通知出して来てウザい。
iPhone からだと、細い回線下ではバッファの読み込みに超時間がかかってウザい。
かと言ってバッファを少なくし過ぎたり、バッファを残さないようにするとかだと利便性に欠いてしまうので大変ウザい。
新環境
そこでこのような構成にしてみた。
WeeChat はサーバの tmux 上で動いていて、 SSH してから tmux attach してから普通にクライアントとして使います。
最初は WeeChat のウラに ZNC を残しておいて、WeeChat も iPhone も ZNC に繋ぎに行くようにしようと考えていたけど、WeeChat に IRC Boucer としての機能があるとわかり、ZNC は落とした。
+----+ SSH +-----------+ IRC +-------------+ | PC | -------------------> |+---------+| -----> | Company IRC | +----+ || WeeChat || +-------------+ +------------------+ IRC |+---------+| IRC +----------+ | LimeChat(iPhone) | -----> | Server | -----> | freenode | +------------------+ +-----------+ +----------+
新環境のメリットとデメリット
ごく短期間使っただけの所感です。
- メリット
- デメリット
iPhone と WeeChat で未読が共有出来るのは本当に便利。
Relay の設定
接続先のサーバごとに待ち受けポートを変えるなど、いくつかやり方があるので、ユーザーズガイドを一読してからお試しになることをオススメいたします。
今回は SSL で接続し、ひとつのポートで待ち受けて、サーバパスワードで接続先サーバを区別する方法を紹介します。
前提
IRC サーバへの接続など、WeeChat を IRC クライアントとしてひと通り普通に使えるようにしておく必要があります。
ここでは割愛します。クイックスタートガイドを読みましょう。SSL 鍵作成
$ mkdir -p ~/.weechat/ssl $ cd ~/.weechat/ssl $ openssl req -nodes -newkey rsa:2048 -keyout relay.pem -x509 -days 3650 -out relay.pem weechat: /relay sslcertkey
- パスワードを設定
weechat: /set relay.network.password **********
- リレー設定
weechat: /relay add ssl.irc 8000
- クライアントの設定
- SSL 有効
- ポート 8000
- サーバパスワード servername:password
おまけ
WeeChat に乗り換えてやったことを都度書くようにした。
- WeeChat を入れてやったことまとめ
オススメプラグインや設定などあれば、是非教えて下さい。
Enjoy IRC!!
YAPC::Asia 2013 に参加してまいりました。
昨年に引き続いて、今年も参加してまいりました。
じぶんのちいささをしった
kazeburoさんのトークを拝聴して、大筋では仰っていること、ご説明されていた内容は理解出来ましたが、なんとなくぼんやりした感じになってしまいました。
UNIXプロセスとかシステムコールについてほとんどちゃんと理解していなかったからでした。
ほう、さすがベテランのスーパエンジニアさんや！で片付けてしまうのは簡単です。
そうではなくて、知ってしかるべきことを知らなかったのであればそれを埋める努力をしなくてはならないし、そういうところ甘かったな、と。
そもそものセンスとか、経験値積んだ上で霊力上げないとー、とかではなく、知ってるか知らないかというところで、何か問題に直面したとき、それを解決するために取れる手法、手段の幅が変わっていってしまうのであれば、学ぼうとしない理由がないですね。と思った次第です。
まぁ、現状の問題を分析して、それを解決するために Monoceros のようなものを作れるかとかっていうと別の話ですけども。。*1
というわけでコレ買いました。
「目次見て知らなそうな事が書いてそうなら、買いじゃないっすかね」とかそういう感じなので買いました。
Rubyですけどね。
『Working with Unix Processes』待望の完訳。 並列処理やデーモン、プロセス生成、 そしてシグナルといったUnixの基礎であるプロセスについてRubyで解説する、 「今どきの」開発者に向けた新しいUnixプログラミングの手引きです。
:
:
スピーカーとして参加したほうが楽しい
コレみなさんおっしゃってますよね。
去年はボクもLTしました。
去年は孤独に過ごす時間が多かったですが、今年は合間でお話するできるような知ってる人もたくさんいて、技術以外の話でも盛り上がったり、そういった面では大変楽しかったです。
でも、去年のLT前の緊張感とか、終わった後に話しかけてもらって嬉しかったりとか、そういう感じのエモーショナルなイベントがいかに素晴らしかったのかということを感じましたわけです。
牧さん&櫛井さん引退のサプライズ人事発表がありましたが、YAPC::Asia 2014 があるならば何か喋りたい。
おまけ
個人スポンサーしたら作ってもらった提灯を会社の名札のとこに飾りましたー
sqlite3-rubyをCentOS5で使うときにはSQLite3をソースからインストールして使おう
さんざんハマっていて、調べてみたらさんざん既出だったけどメモとして残しておく。
sonots:blog CentOS5でrubyのsqlite3を使う に書いてある方法で解決出来ました。
@sonots++
要はこういうこと
sqlite3-ruby は SQLite 3.6.16 以降のバージョンとだけ互換性がある
http://rubygems.org/gems/sqlite3
Note that this module is only compatible with SQLite 3.6.16 or newer.
CentOS5 のリポジトリにある SQLite のバージョンは 3.3.6-6
状況
@sonots とは状況が違っていて、UNIQUE 制約をしているカラムに重複する内容を記録したときに、CentOS5 と CentOS6 では発生する例外が異なるということが起きていて困っていました。
例えばこんなコードを実行する
同じINSERT文を2回発行して、2回目の実行時に発生する例外クラスとメッセージを出力します。
#!/usr/bin/env ruby require "sqlite3" require "tmpdir" dbdir = Dir.mktmpdir("sqlite3") db = SQLite3::Database.new("#{dbdir}/test.db") db.execute(" CREATE TABLE IF NOT EXISTS combatants ( id INTEGER NOT NULL PRIMARY KEY, name VARCHAR NOT NULL UNIQUE )" ) sql = "INSERT INTO combatants (name) VALUES (?)" value = "studio3104" db.execute(sql, value) begin db.execute(sql, value) rescue => e puts e.class puts e.message end FileUtils.rm_rf(dbdir)
CentOS5
このような例外が発生します。コレは想定してないヤツ。
[studio3104@centos5 ~]$ ruby sqlite3test.rb SQLite3::SQLException SQL logic error or missing database
CentOS6
一方こちらではこのような例外が発生します。コイツが俺の求めていた例外です。
[studio3104@centos6 ~]$ ruby sqlite3test.rb SQLite3::ConstraintException column name is not unique
SQLite3 のバージョン
それぞれこのような感じです。
[studio3104@centos5 ~]$ sqlite3 -version 3.3.6
[studio3104@centos6 ~]$ sqlite3 -version 3.6.20
対策後
冒頭のリンクの通りに対策を行ったところ、想定通りの挙動をしてくれるようになりました。
めでたしめでたし。
[studio3104@centos5 ~]$ ruby sqlite3test.rb SQLite3::ConstraintException column name is not unique
英語学習を再開するためにリハビリ的にLINEを使ったらよさそうだった
コードを書いてて、コメントとかhelpとかを英語で書くときに、Google翻訳とかの機械翻訳に完全に依存してしまっていたり、ググって出てきた英語のサイトをそのままChromeに翻訳させたりとかしてしまっていて、そろそろコレではいかんなと思い始めて英語学習に対しての意識が少し高まってきております。
学習の手段として、通勤時間に英語O'reillyを読んだりするというのも隙間の時間を活用してカジュアルにやれるなーいいなーとか思ったけど、英語学習から遠ざかって久しい自分にはまぁちょっと、ほんとにちょっと腰が重いというかそんな感じだったわけですよ。
そんなときにこのエントリを見て、家内とちょっとしたやりとりを最近はLINEでやってるしそこで英語で話すとかだったら超超気軽に出来ていいなー、と思ってやってみたら結構良かった感じです。
こんな感じでやってる。
自分的ルールとして、ゆるーくこんな感じで縛りを入れてます。
- 翻訳された結果があまりにおかしかったりしたら、もう一回ちゃんと自分で考えて送り直す。
- 単語とか慣用句とかはわからなかったらググってもいい。
By the wayを途中と訳されたりとか、翻訳がちょっと微妙なところもあるけど、カジュアルだしまぁリハビリというかそういう感じなのでまぁいいかなと思ってる。
とても気軽で良いですよ！僕と同じような境遇の方はぜひ試してみてください！
あとはコレで紹介されてる「サウンドファースト」の考え方から、週末はこどもたちと一緒にDisneyとかジブリのDVDを英語で観る、みたいなこともしてます。
リハビリが済んだら通勤時間に英語O'reillyを読んだりするのを真似たり、こういうのを試してみようかなと思っております。かしこ。
serverspec の実行をラップする Houcho というツールを作りました。
使い方はgithubのREADMEと、コマンドのヘルプにだいたい書いてあります。 https://github.com/studio3104/houcho
どういうツール？
serverspecの実行対象とspecの組み合わせを定義し、どのように管理、実行するかというところを解決するツールです。
atnodesのようにspecと対象ホストを引数に与えて実行させることも出来ますし、独自のロールを定義しておいてそれを実行させることも出来ます。
多くの場合サーバの情報はすでに他のシステムやファイルなどで管理されていることが多いかと思いますが、CloudForecastの設定からホストグループを作成して、それをhouchoで作成した独自のロールにアタッチすることも出来ますので、CloudForecastをお使いの環境においてはロール管理を多重にしなくてはならないということがなくなります。
CloudForecastを使っていない場合でも、houchoの形式にコンバートしてそのファイルを設置すれば組み込むことが可能です。
あとは実行結果をUkigumoとIkachanにポストしたりも出来ます。
よろしければ
まだ結構微妙なところが細々とありますが、お試しいただいてフィードバックをいただけると大変ありがたいです。 よろしくお願いいたします。
Provisioning Frameworks Casual Talks vol.1 を開催しました。
Provisioning Frameworks Casual Talks vol.1という勉強会を開催しました。
内容については参加者や登壇者の方々のエントリなどをご覧いただくとして、自分は主催者目線で開催においての反省などを綴ります。
個人的反省
mizzyさんにserverspecの話での登壇を依頼しなかった
ほとんどの登壇者が #serverspec の話をしている。 #pfcasual
mizzyさんに #serverspec の話をしていただくように依頼しなかったこと、だいぶ罪深いな。 #pfcasual
なんで登壇依頼しなかったんでしょうね・・・
もともとは、#chef-casual@freenodeでの会話の中で、「Chef Casual Talks」をやろうかーとなっていたのですが、先にやられちゃったんですよね・・・
じゃあどうしようかーってなって、「Provisioning」というキーワードが出てきて、趣旨がブレていってしまった感じになってしまいましたね。。
はい、言い訳っぽい感じになってしまいました。期待されていた方、本当に申し訳ありませんでした。。
昨日の #pfcasual でmizzyさんに #serverspec のお話をお願いしなかったのは咎っぽいけど、興味を持って調べたり使ってみたりする人が増えるだろうからserverspec単体の勉強会をやれるのではないだろうか！！1
って自分が言うのはなんだか違和感がありますけどね(((((((((((っ･ω･)っ ﾌﾞｰﾝ
開催されることが決まった暁には、自分も何かしゃべりたいです。
録音忘れた
riywo's Podcastで録音を配信してもらう予定になっていましたが、すっかり忘れてしまいました。
期待されていた方々、@riywoさん、本当に申し訳ありませんでした。。
懇親会は前金制にするべきだった
登壇者+関係者+αな感じで懇親会をやりました。
26名参加の中規模な飲み会になったのですが、途中で帰られた方も何人かいらっしゃいましたし、これくらいの規模感だと会費は予め徴収しておくのがよさそうですね。
fujiwaraさん本当に申し訳ありませんでした。そしてありがとうございましたm(__)m いつか必ず恩返しさせていただきますので・・・
開催方式について振り返り
ドタキャン問題を回避するべく、MySQL Casual Talks vol.4の方式を採用させていただきました。
・事前登録不可
・先着順入場
参考: MySQL Casualにおける 事前登録不要/先着順受付 という開催方式に関する報告 - まいんだーのはてなブログ
本会においては、19:10くらいに定員である80名に達したために受付終了となりました。
事前登録不可/先着順入場
この方式は、ある程度の集客が見込める前提の上でのみ成り立ちます。
本会は登壇者全員が有名エンジニアでしたので、人が集まらないという心配は無さそうですが、実は直前まで少し不安でした。
広い会場を確保しておいてあまり人の入りがスカスカだったら会場全体が気まずい感じになりそうですし、参加者にも登壇者にも申し訳ないですね。。
実は事前にどれくらいの人が参加してくれそうかということがわかっていたほうが、メリットが多いんじゃないでしょうか。
この開催方式について、「開催側の負担が減るならいいんじゃない？」という意見がいくつか見られましたが、必ずしもそうではないということです。
そして、参加者観点の意見として、「実際に当日行ってみたけど入れないかも知れないという不安があるから事前登録方式のほうが好き」という意見も多くありました。
「当日にATNDなりを立てるとかすれば？」と@uzullaさんがおっしゃっておりましたが、よさそうですね。
前述の問題に対してとても効果的な気がします。
・事前告知は当日にATNDなりで受付を開始するという旨を記載してgistで行う
・興味がある、行きたいと思ったらgistにstarをつけてもらうようにする
事前にそういった触れ込みをしておけばどのくらいの人が参加するモチベーションがあるかどうかということは、事前登録をさせない方式であっても予め計り知ることが出来るでしょうし、行っても入れないかも、という参加側の不安も拭うことが出来るのではないでしょうか。
まぁそれでもドタキャンは出るかも知れないですが、、、
今度また勉強会を主催することがあれば、開催側、参加側双方の不安材料を軽くすることが出来そうな、このuzulla方式を採用してみようと思います。
運営について
会社の先輩であられる@941さん、@dameninngennさん、@python_spameggsさん、@_ishkawaさん、
DeNAの@zabbiozabbioさん、@takusさんにご協力いただきました。ありがとうございました！！！！
さいごに
参加者の皆様、お忙しい中ご参加いただきありがとうございました。
登壇者の皆様、素晴らしい発表をありがとうございました。
ご意見、ご感想などお寄せいただけると今後の励みになります。ぜひよろしくお願い致します。
走り書きをしたので読みづらい文章になってしまいました。。
自作 cookbook を opscode community で公開する方法
chef-xbuild を作った！ - Studio3104::BLOG.new
cookbook を作ったので opscode に公開しました。手順を残しておきます。
sign up & get API key
http://community.opscode.com にアクセスしてサインアップします。
https://community.opscode.com/users/[YOUR USER NAME]/user_key/new にアクセスして、鍵をダウンロードします。
Upload
あとはこんな感じのコマンドを叩くだけ。
CATEGORY は ココからいずれかを選択します。
knife cookbook site share [COOKBOOK NAME] [CATEGORY] -o [PATH TO COOKBOOK] -k [PATH TO PRIVATE KEY] -u [YOUR USER NAME]
成功するとこんな感じに。
% knife cookbook site share xbuild "Utilities" -o . -k ~/Documents/studio3104_opscode.pem -u studio3104 -V WARNING: No knife configuration file found INFO: Validating ruby files INFO: Validating templates INFO: Syntax OK Generating metadata for xbuild from /var/folders/x6/t2nzt5qj6n53yb7_94cxhtjw0000gp/T/chef-xbuild-build20130409-12067-1epvbw9/xbuild/metadata.rb Making tarball xbuild.tgz Upload complete!
終わり！
簡単に公開することが出来ました。が、READMEが崩壊してますので直さないとですね。
http://community.opscode.com/cookbooks/xbuild
