Shibuya Plack/PSGI Conference #1 #plackcon に行ってきた。

Perl 読書

11/20(水)夜にPSGI/Plack初のオンリーイベント（たぶん？）に行ってきました。

Shibuya Plack/PSGI Conference (shibuya.pl) #1
http://atnd.org/events/45276

本編

普通に使う Plack/PSGI Server - @fujiwara

http://dl.dropboxusercontent.com/u/224433/plackcon/index.html

去年、小規模ながらWeb APIを書くことになり、一人、初めてPSGI/Plackを使うと決め、
調べながらMiddlewareを選定し、Starmanを立ち上げ、Supervisordで管理するなどしていた。

fujiwaraさんのトークの前半では挙手アンケートをしていて、
そこで↑がそれほど外した構成でないことが知れて一安心（？）

身内向けなので性能要件は緩く、改修頻度も低いWeb APIだったので、
start_serverやworker数の見極めは適当に済ませていたが、
今後ガチな実装が必要になった際には大いに参考になる内容だった。

『How to build a High Performance PSGI/Plack Server』のその後 – @kazeburo

http://www.slideshare.net/kazeburo/highperfomance-plackcon1

過去、straceは何度も使う機会はあったが知識不足でピタッと解にたどり着けた試しがないorz

次々にシステムコールレベルで最適化していく手腕は凄いなぁと感心するばかり・・・

ISUCONは参会者のツイートやブログを見ていても、計測と見極めやカーネル空間を使った戦略など、
普段、表からは見えない強者エンジニアが見れてすごく刺激を受ける。

HTTP body parser 高速化の実践と解釈 – @tokuhirom

資料はまだ公開されてない様だったけどこれは是非とも見たい！

正直、前述のWeb APIを作った後・・・いや、既に作ってる間から
「なんでこんな仕様にしちまったんだ。。」と思っていた。

その中でも一番に不味いと思ったのが、ログからろくなメトリクスを拾えないことで、
次の機会があれば、発表のような実践重視なアプローチで設計していきたい。

Plack::Requestとエンコーディング – @moznion

ずっとエンドユーザからは隔たれた場所でAPIや運用ツールを書いていたんで、
正直、文字コード周辺は実体験が薄い領域。

それでも、フロントに近い方面の四苦八苦している話はよく聞くし、
今回の発表も「そんな方法もありなのか！」という感じで面白く聞けた。

コマイMojoliciousの話20個くらい – @yusukebe

http://yusukebe.github.io/talks/plackcon-001/#/

PSGI/PlackでWeb APIを書くにあたっては、xaicronさんの下記の記事を参考に、
WAFもO/R Mapperも使わずに書いていた。

第9回　高速なWeb APIの実装とテスト―Mobage APIを支えるノウハウ（1）：Perl Hackers Hub｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/perl-hackers-hub/000901

規模も小さかったのでそれで特に困ったことも無かったのだけど、
選択肢としてWAFも使えるに越したことはないかと思っている。

それでぼんやり選択肢にはMojoliciousとAmon2が上がっているのだけど、
腰が重くて両者とも機能や特徴を調べるにも至ってなかったので、
今回の発表では巷で噂されているMojoliciousの色々について解が得られてよかった。

plackup 2013 Winter Collection - @bayashi

http://bayashi.net/static/slide/20131120/index.html

plackup単体で色々やる話。WAFやアプリに覆われてない生のPSGIを体感できて教材的にも良いと思う。

Plackで実装したHTTP-SMTPリレーサーバHainekoのその後 – @azumakuniyuki

http://sssslide.com/www.slideshare.net/azumakuniyuki/2013-1120hainekoonplackcon1

Mailgun http://www.mailgun.com/ みたいなSaaSにも応用できそうだなー

PSGI に直接対応したテンプレートエンジン – @hkoba

http://sssslide.com/www.slideshare.net/hkoba/plackcon-yatt-lite

苦肉の策で、、という話だったが色々な工夫が見れて面白かった。

.psgiからの卒業 – @songmu

前述のWeb APIを書いちゃってから.psgiを薄くする話を知ってぐぬぬっとした記憶が蘇ったｗ

魔改造Amon2から学ぶポストモダンWAF(仮) – @tasukuchan

会場の空気と全くシンクロしない動画登壇のなんとも言えない感じにやられたｗ

でも、内容はPSGI/Plackと上に載ってるWAFの使い分けみたいな話で興味深かった。

そして、今、本編ではさくっとスキップされたオープニング動画を見たんだがナニコレｗｗ

http://www.youtube.com/watch?v=C1Ma7ghBOVs

全体の感想

既に巷のPerl Mongerの間では当たり前に使われているだけに、
全くついて行けない内容かと警戒していたがたくさん得るものがあって良かった！

運営の方、会場のLINEさん、ありがとうございました！

社内勉強会でMessagePackとtmuxについて話した。

勉強会 tmux MessagePack

すでに開催から1ヵ月が経過しようとしていますが、初めてSlideShareにアップロードした記念とスライド埋め込みのテストを兼ねて書いてみます。

2回目、やってみる？

前回：面白さを求めて社内でエンジニア勉強会をやってみた。 - けめの日記

2月に色々と欲求不満などが高まったことで開催した社内エンジニア勉強会の感触が意外にも良かったので、先月の4/23(火)に第2回を開催してみました。

前回、「技術選択」と「アジャイル」についてややスピリチュアルな内容を話したので、今回はもう少し技術寄りで、かつ皆に通じやすい言語に依存しにくい話題として、メイントーク「シリアライズ」とLT「ターミナルマルチプレクサ」の2本を話しました。

話した内容

JSONやMessagePackを試した話。

小規模ながらゼロからサーバサイドを作る機会ができたので、シリアライズ周りで色々試した話をしました。

キャッシュにMessagePack, フロント(JS)向けにJSONベースのAPIと、探せばいくらでも事例が見つかりそうな実装ではありますが、実際にデータストアやログに書き出し、動作をテストしていると思わぬところで嵌ったりして考えさせられることが多くありました。

正直、Perl以外のクライアントライブラリは触っておらず、MessagePackの"データコンテナ"という位置づけも恐らくうまくは説明できません。また、SOAPやXML-RPCの全盛期にはコードを書いていなかったので、近頃のRESTfulなAPIとの違い（誕生の背景や用途、長所、短所、など）も理解にはほど遠いです。

そうした知識の不足もあり、今回はあまり冒険はせずに無難な使い方で使用感を得ることを狙ったので、その点ではうまくいったと言えると思います（ちょっと盛ってます。そこまで深くは考えてないｗ）

ターミナルマルチプレクサ使ってますか？

去年・今年の新人さんも参加していて、チームのメンバーも基本的にGNU screenだけを使っているようなのでtmuxの基本操作デモを行いました。

自分はターミナルマルチプレクサのライトユーザなので、正直言ってGNU screenとtmuxの両者について明確な差異や使い分けなどは説明できません。早い話が今のところはミーハーな感じにtmux使ってますｗ

さて次回は・・・

ぼんやりと考えているのは・・・

  • 何でもアリのLT大会

あまりガチネタが続くと発表する心理的なハードルが高くなってしまい俺が聞き手としておいしくないアウトプットの習慣化が進まないので、思い切って「写真多めでペットのネコを愛でるLT」とか「俺的オススメ映画/音楽を語るLT」とかやってみるのも面白そう。

  • Perlネタ尽くし

最近、PSGI/Plackやcartonを触り始めたのでメイントークでそれらの概要と使用感を話し、LTでは過去に参加したYAPC::Asia Tokyo 2011,2012の印象を話しつつ2013の宣伝をしようかな、と。


さて、次回はいつ頃の開催できるかな・・・

（1ヶ月前の話ですが）PerlCasual #05が大変面白かった！ #perlcasual

勉強会 Perl


（記憶が新しいうちに書けばよいものを・・・）

PerlCasual #05 : ATND

本編

普段、仕事では運用ツールやAPIの保守を中心に行っているので、漠然とWebアプリケーション開発の技術領域の幅広さやスピード感に惹かれている。
それなら「自分で作ればいいじゃん？」という話なのだが、如何せん"憧れは強いがやる前に考えすぎる"というダメな性質なので、今回のメイントークではモチベーション（のおすそ分け）やWebサービス開発のイメージをたくさん頂けて良かった。

@ruikさん「 Perlでの"小規模"アプリ 制作事例」

  • 組織の大きさを感じさせないカジュアルさが凄い！
  • （残念なことではあるけど）ちゃんとサービスの「終わり」が設定されているのは良いと思った。
  • 「技術の選定→プロダクトでトライ→失敗は次で生かす」の事例として大変わかりやすかった。

@koba04さん「元タワレコ店員×Perl×Webサービス」

  • プログラミング未経験のタワレコ店員がエンジニアになって思ったこと を見てぐっときた方のトーク！
  • ビジネスではなく技術を試す場としてのWebサービス作りという感じが自分がやってみたいことに近い。
  • 有限のモチベーションをうまくコントロールする点に触れていて良かった。
  • データストアからクライアントサイドまでたくさんの"トライ"があって楽しそう＞＜

@sugyanさん「ライブコーディング」

  • 率直に「え、みんなこんな早さでコード書いてるの！？」と・・・
  • 自分ももうちょっとエディタの力を引き出してコードを書きたいと思った。
  • コマンドラインとPerlだけでなく、HTMLテンプレやブラウザを行き来するのを見て「一人でWebアプリを書く」という雰囲気を感じ取れた。

ところでここまでみんな1982/83世代なのは偶然なのか・・・？
自分も同い年ということもあって親近感と焦りが半端ない＞＜

LTはスピリチュアルだったりPerl関係なかったりして大変カジュアルで面白かったｗ
ただ、Yappoさんの例外処理の話は↓の部分が刺さったので試してみようと思う。

ついに顕在化しはじめた Exception リスク より

以外と $@ の扱いは難しくて面倒なのです。例外処理中に例外発生したら？例外発生した直後に DESTROY のなかで eval してるオブジェクトがあったら？

懇親会

恐れ多さ無限大なオペレーションエンジニアの方々と同席したが、"PerlCasual"の名の下に「本番のPerl環境ってどう構築してますか？」とカジュアルに聞くなどした。

いくつものPerl製Webアプリを運用している現場の話や、数日前に読んだPerl環境についてのブログエントリーの背景、便利なのは良いが慣れた環境（会社,PaaS,etc）を離れると何もできない人を作るのはまずい、など色々な話を聞けて（一方的に）大変充実した時間を過ごさせて頂きました。いつかは返したい。

感想

YAPCで凄い人を見るときの高揚感とは異なり、同じように悩み・試行錯誤している人の身近なエピソードを聞ける良いイベントでした。次あったらまた参加したい！

NHN Japanさんのカフェもイベントのカジュアル感に合っていて良かった。右の方にあった畳っぽいスペースが羨ましいｗ

面白さを求めて社内でエンジニア勉強会をやってみた。

勉強会

はじまり

2010年末から外部の勉強会に行くようになり、自分の「知識と経験」、組織の「（経験や機会における）加速装置という魅力」に弱さを感じつつ、漠然と「面白そうだなー」という羨ましさも高まり、ついに社内で有志によるエンジニア勉強会を開催してみました！

狙いとしてはこんな感じ。

  • 個人としては「仕事に依存しないアウトプットの場を作り、自分のモチベーションを高める」
  • 組織としては「集団で我慢大会なんかやってないで、身近なところだけでも前向きな相乗効果を出す流れを作る」

準備

開催にあたって気をつけたのは下記のようなところ。

  • 面倒を避けるため開催は業務時間外。設備を借りるのみ。発表資料作りは全て休日。
  • 自由参加。わざと意識高めな趣旨を設定して「賛同できる人だけ来てね」と書いた。
  • 初めての試みなのでスモールスタート。開催の告知範囲も面識のある範囲に限定。
  • 自分も含めアウトプット慣れしていないのでLT枠も設け内容は制限しない。

自分が「めんどくせぇ・・・」と言って止めてしまわないための対策ｗ

結果

期待以上の大成功でした！達成感があり過ぎて今軽く燃え尽きてる（汗

  • 開発/運用/ネットワークのエンジニアに加え、マーケターやPMも参加してくれた。
  • 発表後はよくある質疑応答ではなく、自然と発表を起点とした意見交換になった。
  • 今年の新人を含む若手が非常にLTらしいノリで盛り上げてくれた。
  • 何よりも、終わって「楽しかった」「次回もやるでしょ？」という声を沢山貰えた。
  • 個人的には新卒セミナーのお手伝い以外で初めて発表を行えたのが大きい。

反省

うまくいかなかった部分は主に自分に関連するところで・・・

  • 普段使ってない設備だったので機器の接続に手間取りスタートが遅れた。
  • 想定していた時間の2倍ぐらいしゃべってしまい盛大に時間オーバーorz
    • 長年の"色々"が篭った内容ということもあり話しているうちに広がり過ぎた。
    • 発表数不足を想定して自分が用意した4本のうちLTx2は次回に見送った。

スイマセン、スイマセン＞＜

発表内容

プライベートで書いた資料だけど、本のコピペや社内事情を考慮して編集するのは大変なので概要だけ載せておきます。

「どんな技術を選択するか」について ～目の前の課題を"片付ける"の先の話～

  • 技術の採用を軽く見すぎてない？という話
  • 開発～運用の過程で関わるメンバーとプログラミング言語の親和性について
    • OS標準搭載の運用を支える言語としてのPerl,Python（Ops）
    • 運用支援ツールの界隈で利用が広がっているRuby（Ops）
    • HTML,CSSから始まり守備範囲を広げた先にあるJS,PHP（Design）
  • DevOps
    • バズワード化してるのでmizzyさんの資料やJohn Allspawの発言を引用
    • 【俺解釈】開発と運用の良い関係を起点とし、ビジネスをうまく進めるための文化。またそこから生み出されたプラクティスやツールなど。
    • 参加した勉強会とそこで話されていた内容を紹介
      • DevOpsカンファレンス,オペカジ！,CROSS2013「継続的○○のゲンバのハナシ」
    • 書籍「ウェブオペレーション」の紹介
    • DevOpsという点から自分たち歴史を振り返る
      • Dev,Opsの分業の中で共有部分として残ってきたもの
      • 自前で作ってきた構成管理や統合監視/モニタの存在
      • メトリクスを集め可視化し、DevでもOpsでもない人に見せるという試み
      • DevOpsは全く新しい何かではなく、我々のゲンバにもあったよね？
  • 顧客のニーズを追えているのか？
    • 引き離されていなかった時代（共用）と危機感高まる今日この頃（IaaS,PasS）
    • なぜ引き離されたのか、という考察
    • 引き離されないことで成功している他社の事例

ゆるふわアジャイル！～3歩手前から、少しずつ～

  • 受託と自社サービスは違うよね？
    • 就活生にはよく誤解されてます
    • 利用者との距離感,何に対価が払われるのか,ドキュメントの価値,収入のタイミング
  • アジャイルの紹介
    • アジャイルソフトウェア開発宣言
    • 手法は１つじゃない。自分たちで作ったっていい。
    • 身近な疑問とアジャイルなプラクティスの答え
    • "巻き込み"の必要性
    • 自分たちでできることから、という提案
      • この勉強会は「変化への追従」と「チームへの投資」
      • スタンドアップミーティングならすぐできる
    • 継続的デリバリーへの道
      • 様々な技術や道具を使いこなさないと回らない
      • 一歩ではなく半歩から始めてみては？
        • 一人作業でもローカルリポジトリを使う
        • 使ってる言語のテストツールに慣れる
      • アジャイルは「目指す方角」程度に考えてみる
        • 半端に試して「アジャイル使えねぇ」ってパターンは避けたい
        • まず踏み出すべきは身近な開発改善
    • 「何のために使うのか」を理解することで初めて大きな効果を発揮する道具もある。
      • ツールを入れる前に本読むのもいいかも。読書会もあり？
    • 本の紹介
      • 「アジャイルサムライ」まずはコレ
      • 「アジャイルプラクティス」天使と悪魔に学ぶ
      • 「サムライエピソード」みんなの事例
      • 「SCRUM BOOTCAMP THE BOOK」最近買ったよ

実際は資料1で話9ぐらいの割合で話したので参考程度に。

今回はだいぶスピリチュアルな感じだったので次回は技術ネタでいきたいなー

エンジニアサポートCROSS 2013に行ってきた。 #CROSS2013

勉強会

去年に続き今年も参加してきました。

  • ギークのターニングポイント
    • 「パネラーが凄すぎて参考にならない」
      • （感想）確かにその通りかもｗでも「ここまでやっちゃっても大丈夫！」という励みはあった。
    • 結婚して守りに入るパターンと、むしろドライブがかかるパターン。
      • （感想）どちらも状況や関係を想像できるけど、実際なってみないとわからないところだなー
  • ニフティクラウド「C4SA」について
    • ランチセッション
      • （感想）エビチリなど入った中華弁当がうまかった。ごちそうさまでした！
    • C4SAはnifty.comを支える基盤から生まれた。一番便利に使ってるのは自社のエンジニア。
      • （感想）amazon.com基盤から生まれたAWSや、Webサービスを作ってるペパボが作ったSqaleに通じる。想像上の利用者ではなく、具体的な利用者がいるという点が強い。ぶれない。
      • （感想）長年、共用レンタルサーバをやってきた身としては、一世代前の技術でぶつかった壁を越えた先にPaaSがいる感じ。IaaSに比べまだまだ個性が出そう。
  • 企業CROSS DeNA x グリー x Aiming： 大企業・ベンチャーが語る「スクラム」開発 (ä»®)
      • （感想）何冊かアジャイルの本やセッションを見てきて、現場の良くないところと各プラクティスが（脳内で）結びづいてきた今日この頃の気になる話題。
    • 失敗として「ただ集まるだけのMTG」や「増える一方で上に伸びていくバーンダウンチャート」、「巻き込み過ぎて長くなってしまったMTG」などなど
      • （感想）あぁ、１番目とか割と取り組みやすいと思ったけど甘くは無さそうだ。。
    • 成功として「縦割りの壁が薄れた」や「振り返りの効果が少しずつ出てきた」など
      • （感想）前者は巻き込む力が必要そうだけど解決できればでかい。結局、後者の繰り返しが大事なのか。
    • 外部コーチやデジタルな支援ツール、スクラムマスター、など
      • （感想）まだ「（某サムライを手本に）試してみたい」の域なので本格的に取り組むなら外せ無さそう。
      • （感想）専属のポジションを作るにあたっての選任や評価は半端な気持ちでは手が出せない。（正直、自ら現場離れて管理を目指すモチベーションは無いしなー）
  • 継続的サービス改善のゲンバのハナシ
    • ＼プシュ！／
      • （感想）だいぶぶっちゃけてて良かったｗ あとtagomorisさんの振り方がうまいｗ
    • そもそも何を改善するの？「数値から見つける」「自分がユーザ視点で探す」「昭和大事」
      • （感想）扱ってる商材や役割のバラバラ具合がいい感じに出てる。
    • どうやって測る？「メトリクス監視」「"自分が困ってる"ã‚’"みんな困ってる"に置き換えるクレームは参考にならず統計分析してる」、「SNS等から感想を拾ってくるbot」など
      • （感想）クレームの品質が酷いは同感＞＜
      • （感想）メトリクス監視が一番入りやすそう。統計分析は利用者像や"正しい状態"が定まってないと難しい。SNS監視はBtoC向けか。
    • 立場間の対立や改善を推し進める方法「自分で勝手に動いてから成果見せる」や「伝わるように見せる」、「相手が折れるまで言い続ける」など
      • （感想）技術力・プレゼン力・根気。後ろに行くほど苦手だｗ
    • サービスの作りっぱなしや閉じ方「採算見て決める」や「政治力」、「株価に響く」、「おしまい姉妹」など
      • （感想）最後のやつが凄すぎるｗ
  • 継続的システム運用のゲンバのハナシ
    • 技術的負債、どしてる？「負債満載の状態で自分の所に来る」や「負債を返すことで夜寝れる」、「ホスティングの事情」、「経営陣の理解」など
      • （感想）いつの間にかサービスが作られてるとか、アラートが届いて存在がわかる、は怖い＞＜
      • （感想）ホスティングは動くコードも、投げるクエリもお客さんが握ってるからちょっと特殊ですよね。。
      • （感想）経営陣が技術的負債が増えると成長が鈍化するとこまで理解してる環境！
    • 自分と家族の健康を「１年かけてH/Wリプレース」や「夜中にレシピを検索する人はいない」、「一次対応を外注して夜間シフトを無くした」、「当番制でマナーモード」、「アラートが多くて嫁が不機嫌」など
      • （感想）独特なピークタイムが運用の負担を下げている事例。な、なるほど・・・
      • （感想）お金かけて外注してもっと大事な事に注力。準備と理解が大変だけど効果は大きい。
      • （感想）家庭の話や対応フローの話を聞くとDevOpsカンファレンスを思い出す。どこも試行錯誤してる。
    • 変化の受け入れ的な話「MongoDBとか（ｒｙ」や「試してダメなら外せる仕組み」など
      • （感想）新しいものガンガン入れたり、システムごとに構成要素がバラバラなのはだいぶ辛そう・・・
      • （感想）クックパッドの事例は、動的サムネイル生成の話と合わせてWEB+DB PRESSで読んだ気がする。
    • 人材について「しっかり教育とか受けた記憶がない」や「ギリギリの人数」、「嫁と一緒のベッドで（ｒｙ」、「（結婚や体力面で）チームビルディングが大事に～」、「採用してます！」など
      • （感想）Operation Engineers' Casual Talksでもこんな感じだったな・・・
      • （感想）新人育成|中途採用を問わず人員の確保と、家庭も含めた負担の軽減はどこも大変そう。。
      • （感想）ここら辺で登壇者の携帯にアラートメールが飛びまくるという事件→同僚さんが対処（イケメン過ぎｗ

（最後のセッションは飲んでふらふらしてたのでスルー）

今回、デザインや法務に関連するセッションは聞かなかったのでCROSS自体は足りないのかもしれないけど、だいぶ色々な「ゲンバ」を見れて良かった。ありがとうございました！

また来年もぜひぜひ！！

（今さら）Operation Engineers' Casual Talksの感想メモ。 #operationcasual

勉強会

もう１ヶ月以上前（2012/12/14）だし、年も跨いでるし・・・と思ったけど、今でも印象に残ってることはきっと大事なことなんで軽くメモだけ。

  • 「ほげエンジニア」の定義について（tagomorisさん）
    • 「自分を何者と名乗るのか？」という話。
      • （感想）自分は消去法でプログラマかなーっと漠然と思ってたけど、横割りの組織でミドルウェアやOSから完全に切り離されてコードだけ書いてる環境の話を聞くと物足りなさそうな印象を受けるので、関わりたい範囲をもっと縦に抜いた名前を持った方がいい気がした。
  • 「枕を高くして寝る話」 （fujiwara）
    • 全くコードを書かない状態からステップアップしていく流れが綺麗にまとまっていた。
      • （感想）プログラマをやれ、というのではなく、課題を解決する道具という目的がスタート。
    • ちょっと試したり、自分用の道具としてのコードもちゃんと管理する話（Dropboxに同期しておく）
      • （感想）家で作業してて社内Wikiを参照したくなるあの感じに近い。
    • 慣れてきた頃に凝った方法をとり過ぎる時期に気をつけたい「コードを書かないという選択」
      • （感想）2,3ヶ月後に「うわ、全然イケてねぇ…」って自分で思うパターンだｗ
    • 自分用のコードから皆が使えるモジュールにするのが皆に嬉しい形。
    • （CPANなど）ちゃんとしたところに公開するプレッシャーやフィードバックが良い効果を生む。
      • （感想）作法とかわからないしなかなかネタもないけどいつかやりたい。
  • パネルディスカッション（tagomorisさん、fujiwaraさん、lamanotramaさん、myfinderさん、mikedaさん）
    • コードを書くべきか？という点については「プログラミングには適正がある」「どこまでも深入りする必要はなにのでは」「広義のコーディングは皆やってる」など
      • （感想）特別な行為として重んじるような意見は少ない印象。
    • 割と「必要なときに選択肢としてコードを書く。ただそれだけ。」という感じ。
      • （感想）インフラ扱ってる方はいい意味でドライ。
    • 勉強方法として、自分から（担当者など）フラグを立ててしまうのが良い。
      • （感想）たしかに無期限だと続かないし、最初からチームの課題解決という恩恵も得られるのでよさげ。
    • インフラ業務のためのコードはあまりテストを書いてないが、複数が使ったり、変更が繰り返されるならあった方がよい。
      • （感想）仕様書としてのテスト。デグレードを検出するためのテスト。
    • 後輩の教育について「（厳しい感じの意見。でも面倒見もよい）」や「一番下手くそであれ」、「自分で荒野を開く方が合ってる」などなど
      • （感想）厳しいけど面倒見も良い指導、新人の頃にいたスーパーエンジニアさん思い出したわ・・・
      • （感想）自分が新人の頃は一番下手くそであれ（情熱プログラマだっけ？）に助けられた感ある。
    • 不満とか転職についての色々
      • （感想）あぁ、気をつけよう・・・

メモ）「おぺかじ」まとめ - Togetter http://togetter.com/li/422826

SSH接続時にホスト名を付けたtmuxウィンドウを開く方法

tmux

いわゆる踏み台サーバを介して作業を行っている環境では、踏み台サーバ上で起動したscreenやtmuxの中で他のサーバにSSH接続しているケースが多いかと思います。

その場合、たくさんのサーバを管理していると下記のような煩わしさがあります。

  • 並行して作業を継続するにはsshコマンドを実行するウィンドウを新たに作る必要がある。
  • 複数のサーバに接続しているとステータスバーのウィンドウ名が「1:ssh*」では区別できない。

screenを使っていた時は @mounemoi さんに教えてもらった「screen利用中にsshコマンドを実行すると、ウィンドウ名がホスト名（正確にはSSHコマンドオプション）になった別ウィンドウを開く設定」で解決していました。

tmuxに移行するのに伴い同じことができないかと模索した結果、上記の方法をベースになんとか形になったのでまとめてみます。

~/.bashrc

# ssh 時に新規ウィンドウを作る
ssh_tmux() {
    ssh_cmd="ssh $@"
    tmux new-window -n "$*" "$ssh_cmd"
}

if [ $TERM = "screen" ] ; then
    tmux lsw
    if [ $? -eq 0 ] ; then
        alias ssh=ssh_tmux
    fi
fi
  • 「tmux lsw」の結果を評価しているのは、screenも併用していた場合への配慮です。
  • 「-n "$*"」ではsshコマンドの引数をずらっと与えているので、ポート番号やユーザ名を指定していると大変残念なウィンドウ名になります。
    • 対策として上記を指定する代わりにSSH接続先の.bashrcに「printf "\033k$HOSTNAME\033\\"」を書いておくという手があります。（ログイン後にウィンドウ名がホスト名に書き換わります）