Tremaday #8に参加してきました。
Tremaday #8に参加して登壇してきました。
非常にレベルの高い講演の中、多少場違い感のある内容でしたが、一服の清涼剤程度になれば良いかなと思います。
発表資料
www.slideshare.net
この中で、だいぶ真田さんのことをDisってるんですが、少しフォローをしておきたいと思います。
宇宙戦艦ヤマトでは
- 色々あって地球滅亡まであと1年
- コスモクリーナーDを取りに来いというメッセージと波動エンジンの設計図が送られてくる。
- 送信元は地球から14万8千光年離れたイスカンダル星
つまり、物語の始まりでまず波動エンジンを作るところから始めなければならないのですが、 設計図という割には波動エンジンや構成部品の材質など肝心なところは省かれており、 宇宙飛行の途中で入手した材料を使い急遽補修するなどの場当たり的対応を強いられます。 宇宙船を旅の途中で材料調達して直すんですよ？意味が分からない。
そもそも、宇宙戦艦ヤマトの飛行テストすら行われていないのであり、 一発始動させた真田さんマジハンパないッス。
そんな綱渡りでイスカンダルまで到着したら、渡されたのはコスモクリーナーDの「部品」。
どういうこと？イジメ？ そんな部品から帰りの道中にコスモクリーナーDを完成させてしまう真田さん。 でもテストしないからコスモクリーナーを動かしたヒロイン死んじゃいますけどね。
ほら言わんこっちゃない。。
でも最終的にはヒロインは蘇りますので結果オーライと言えなくもないでしょうか？ ここまでくると、この天才にはテスト必要ないよねという気がしてきます。
テスト？ お前それ真田さんの前でも同じこと言えんの？
私のような、天才ではない人間にこそ、テストは必要なのです。 そんなわけで、私もこれからmininetの使い方を習得しようと思います。
算数と足し算の順序、これからの教育
この件が話題になっているようなので一言。
小学校の算数教育で、 「車が5台止まっています、9台来ると、全部で何台になりますか」 という答えに9+5=14と書いた答案がバツになるのはおかしいのでは？ という内容です。
私の意見はバツはおかしい、でも 5+9=14 のほうが 9+5=14よりも優れた回答だと思います。 テストは理解度を測るものであり、マルをつけてしまうと、そこに疑問が発生しませんので、改善の機会が失われかねません。 三角をつけるくらいが適当ではないかと思います。
等価交換だからとかそういうことではなく、日本語として問題文を解釈し、素直に数式に表現すると、5+9=14 になり、この形は誰の目にも「問題文がそのまま反映された数式」になると思います。 例として、
<?php $Current=5; $Arrival=9; //現在の数に新着の数を足す $Total= $Current + $Arrival; echo 'Total Car = '.$Total."\n";
<?php $Current=5; $Arrival=9; //現在の数に新着の数を足す $Total= $Arrival + $Current; echo 'Total Car = '.$Total."\n";
上記2例で結果は変わりませんが、2例目はコメントと式が逆になっています。 変数の数が多くなってくると単純な足し算でもコメントと合っていないと理解しづらくなっていきます。 CurrentとArrivalという二つの英単語の意味がパッと分からなかったりする場面でも、対応が取れている最初の例では意味が分かりやすくなっています。
小学生の算数のテストであっても、文章題を解くときには計算力だけでなく文意を正しくとらえること、 数式として表現することが求められています。 数式は単なる計算過程ではなく、自分のイメージを表現する手段でもあります。
回答の際、文章題を見ていない他人でもイメージしやすい形で、文章が素直に式に反映されていれば、 それは素晴らしいことです。将来違う場面で自分の考えを他人に説明するような場面でも、きっと役に立つと思います。
2例目も決して間違いではありませんが、1例目のほうがなお良いという意味で満点ではありません。 私の子供時代はこのようなことは深く考えずに適当にやってきましたが、 今エンジニアになってみて、単純なことを素直に分かりやすく表現することは、非常に重要だと感じています。 これからの子供たちはこのようなところから、少しずつ基礎を積み上げることを意識して教育されていくのかもしれません。
がんばれ！ 子供たち！（笑）
パケット解析を簡単に行う方法
皆様こんにちわ。 パケットキャプチャ使ってますか？ 今回はキャプチャファイルを簡単に解析する方法をご紹介します。
以前、パケットキャプチャの敷居の高さについて書いたことがあります。
要約すると、パケットキャプチャでは何がおかしいのか分からないことが「難しい」ということになります。 なので、何を無視するか、何に注目するべきかを絞り込む方法について紹介します。
パケットキャプチャ教の普及にまつわる問題
私はユーザー企業の情報システム部門で勤務した経験があります。 そこでシステム上の問題が発生するたびに、トラブルシュート（障害対応）を行わなければならないのですが、私はいつもパケットキャプチャを使用して問題に対処していました。この方法は非常に精度よく問題に対処できるため、同僚にも勧めたのですが、反応が良くありません。
トラブル解決のときには、なるべく詳細に問題の発生原因や見つけ方などを情報共有し、社内勉強会も数回開催しましたが、こちらの説明を理解しているのかいないのか、興味がないとしか思えないリアクションをされるのがいつも不思議でした。だったら勉強会に出席するなよ！ と割と毎回思っていました。
なぜこのような反応をされてしまうのか、ということを考察してみたのですが、 パケットキャプチャを使ったトラブルシュートの実例を聞いていると、問題解決に必要な前提知識の多さに引いてしまうことが原因ではないかと思い当たりました。
パケットキャプチャはネットワークのデバッグ行為に相当します。 デバッグとはコードを解読する能力のある人が、入出力やコードの記述を調査することで解析を進めます。 入出力の内容が理解できない人が実施することは基本的にできません。
そのため、分からなさ過ぎてテンションが下がってしまうのではないかと考えました。
具体例
ここで少し例を出したいと思います。 パケット解析は間違い探しです。 しかも、多くの場合「間違った絵」だけをみて、間違いを指摘しなければなりません。
以下の絵について間違いを指摘してみましょう。
未来の世界の猫型ロボット
予備知識のない状態だと、
- このロボットは黒猫タイプ？
- ツメは標準装備なのか
- 暗闇で目が光りそう
ということで違和感があまりありません。
ハッ、もしかして、声が間違いなのでは？と、思ってしまうかもしれませんよね。
正解は「何もかも違う」です。
間違えた方はいないと思いますが、それは「未来の世界の猫型ロボット」というキーワードから既知のキャラクターをイメージできるからです。
予備知識のない状態で、比較対象のない間違い探しを行うことは、
非常に困難を伴うということがお分かりいただけたかと思います。
解決策
それではどうしたらよいか。 答えは「比較対象を常に用意し、見比べることを前提にトラブルシュートをする」です。
以下のサイトで 継続的にパケットを収集する仮想アプライアンス、 「Sonarman」を無料で配布しています。
Sonarmanについて
無償版配布ページ
この仕組みを利用して、常に正常系と異常系を見比べてトラブルシュートが出来るようになれば、2種類のパケットキャプチャの差分だけを意識して解析すればよいということになります。
そのため、結果的に難易度が下がり、解決のスピードが速くなるのではないかと思います。
もしよければ使ってみてください。
シェルの変数を分割する
このブログはテクニカルノートなので そろそろ真面目に技術的な備忘を書き溜めていこうと思います。
私はほとんどPHPとシェルスクリプトの組み合わせでプロダクトを書いているので、 そのあたりのことを書きます。
(動作確認はDebian wheezyで行っています)
利用シーン
WEB画面から何かの値を入れて、その値を元にバックグラウンドでシェルを動かし、 その値を保存しておきたいとき。 値を保持する専用ファイル(test.dat)をPHPで作成し、値を書き込みます。
その値をシェルから呼び出すときには以下のようにします。
test.dat
message=test
test.sh
#!/bin/bash source ./test.dat echo $message
地味ですが割と頻繁に使うテクニックです。
モロボシダンとSonarman
2015年、6月末にリリースした「Sonarman」、継続的にパケットキャプチャを取るための製品なんですけども。無償のVMバージョンは弊社の運用現場でも使われてまして、色々思うところなどひとつ。
論理的なトラブルシュート
先日、尊敬する大先輩と一緒に昼食をとったのですが、
そのときウルトラセブンの話になりまして、特撮ものって尺が短いから謎解きとか結構適当ですよねという会話で盛り上がりました。例えば。。
タケナカ参謀「なんだこれは」
モロボシ ダン「未知の宇宙金属です」
...そうなの!？
何で断言するの？
別の場所で金属のかたまりを発見
モロボシ ダン「これは地球の物質ではない。叩くものを貸してください」
→叩き割る
破壊された金属内部から機械のようなものが現れる
モロボシ ダン「発信機つきの電子頭脳だ」
...えっ本当!？（バカボン風）
もうちょっとよく確かめたほうがいいんじゃないでしょうか？ 大丈夫ですか？
まぁここまで極端じゃないですけど、トラブルシュートするときには設定変更をトライアンドエラーすることがあります。これは別に普通です。故障箇所を見極めるときに誰しもがやることです。
ですが、全くの当て推量で適当にやってしまうと別の問題を引き起こしたり、時間ばかり消費してしまいます。
最悪もとに戻せないなんてことも…、あるかもしれません。
モロボシ ダンのように、根拠が不明なのに怪しい物体を割ってみる、みたいなことは、時間の限られた特撮の物語上でしか許されません（笑）
指針としては、何を根拠に変更を試すのか、人に説明できるレベルまでには問題の現象と仮説を組み立てるのが理想でしょう。そんな時、直接ネットワークのIN/OUTを可視化できるパケットキャプチャが役に立つというわけです。
私の実感としては大体4割近くのネットワークトラブルが疎通の問題です。
クライアントから出力されたデータがサーバのプログラムまで到達しないというレベルです。
つまり、パケットキャプチャさえ見ることができれば4割の問題は無条件で障害箇所を切り分けできるということです。全く難しいことはありません。
パケットキャプチャを仕込むということは少なからずネットワークに変更を加えるということですので、慎重になる気持ちも大変よく分かるのですが、障害が発生したときに必ずそのキャプチャが手元にあるという状態は非常に快適です。
先日製品版のSonarmanには蓄積されたパケットキャプチャを解析して障害の予兆を検知する機能をリリースしました。設定漏れや、不整合などを見つける、ネットワーク監査のような目的にも使用できます。遠隔にある目の届かない場所（海外など）でネットワークの障害対応を行うのに最適な製品です。
無償版のダウンロードはこちら
ソナーあれば憂いなし。
Sonarmanに興味がある方は、ぜひお問い合わせください！
@Clorets8lack
オリンピックにおけるIT技術者ボランティアの件について書いてみる
この話はなぜここまで炎上してしまったのか。
もともとは CEATEC JAPAN 2015で開催されたパネルディスカッションの内容が発端だ。
元記事
その後出たフォロー記事
これらの記事に出てくる一般社団法人コンピュータソフトウェア協会（CSAJ）会長の荻原氏の発言内容が物議をかもしている。
要約すると、
- 新しい団体を作った
- IT業界にはすでにたくさんの業界団体がある
- IT業界はひとつになって国に対して働きかけるべきだ
- 活動のひとつとしてIT教育の拡充がある
- 2020年までにセキュリティ技術者が4万人必要
- 国の費用でIT教育を拡充させる見返りとしてボランティアでオリンピックのサイバーディフェンスをやろう
ということのようだ。
他にもフォロー記事で発言しておりそれがまた炎上に燃料を投下するのであるが、それについては後述する。
まず、基本的な前提認識として、「使い物になるIT技術者は簡単に増やせない」という現実がある。
この話ではセキュリティ技術者の不足が取りざたされている。セキュリティ技術者は比較的育成が難しい職種で、これからセキュリティ技術を学ぼうとする人間が実践的な学習環境を用意するのが難しい。そのため、国の支援を、ということではないかと思われる。
しかし、この計画にも突っ込みどころがたくさんある。あと4年しかない状態で、使い物になる4万人の技術者育成はおそらく相当難しい。資格試験の合格を目指すのならともかく、サイバー戦争を引き合いに出して議論するほどのレベルにすることはおそらく不可能だ。スケジュール、目標ともに現実離れしていると感じる。
サイバー戦争がどのように行われるかということは実体験を持ち合わせているわけではないが、現実の兵器に使われているIT技術や軍事知識については井上孝司氏の連載に詳しい。
私の感想だが、とてもボランティアでできるようなレベルではないだろうと思う。セキュリティというものは普段の積み重ねによって整備する部分が大きい。1ヶ月間大量に人を動員したからといってどうにかなるほど生易しい業界ではないだろう。
また、ボランティア（無償）というお金の部分についても問題がある。セキュリティ担当者に十分な報酬を払わないとどうなるかを端的に示した例が先日のベネッセ事件だ。サイバー戦争、国防というキーワードに対して恩返し、ボランティアといった単語を対応させることが、まったく現実を無視しているように思われるのだ。
業界を代表して何らかの提言をしようとする氏の立場に於いて、大変残念な発言であると思う。
ボランティアに関する言及にはInterop Tokyoとの比較が登場する。
Interopはもともと技術者の自発的行動が元になり、技術者同士楽しくワイワイやっているところに、協力者が続々と出てきたことが今日の成功につながっている。他人から押し付けられたものではないし、教育機会の提供から始まっているものではない。
「東京五輪に向けて、エンジニアがボランティアで参加するという取り組みについても、同様の成果を期待できるのではないだろうか。」
とする氏の認識は誤りである。
また、IT業界の労働環境についての氏の見識も耳を疑うものだ。
――ソフトウェア産業そのものが“ブラック化”しているという指摘もある。短期間とはいえ、ボランティアとして働かせることは、それを助長することにつながるのではないか。
そうは思わない。ブラック化といわれる背景にはいくつかの理由がある。そのひとつは、ブラック業界であるという印象を持たせる動きがあることだ。
――エンジニアの労働条件を高めるためには、労働組合という手法もあるのではないか。
エンジニアは力を持った人材のことを指す。どんな企業に行っても活躍できる技量を持っているはずだ。そうした業界で労働組合の存在はあわない。
一蹴である。
労働者の利益を考えているならここはもう少しきちんと説明するべきではないか。
国から金をもらいやすくするのではなく、経済活動によって自立しなければその業界に未来はない。IT業界は自ら稼ぐ手段を持っているのだから、どうすればそれをもっと発展させられるかを考える立場の人間がきちんと説明しないのはまずい。
経営者と技術者
ここまで、氏の発言について個人的な感想を書き綴ったが、
一介の技術者であり、規模は小さいが経営者でもある私には思うところがある。
- IT技術は、買う側がその価値を理解できないことが原因で、うまく金に換えられないことがある
- 現在のIT業界の多重下請け構造には、知名度や単純な価格で購入を決める買い手側の不見識、無理解にも一因がある
- そんな中、適切なレベルで世間の需給を満たすことは非常に難しい
- 現実的な解を考えたとき、少しでも現状をマシにするためには何らかのキャンペーンやイベントを張り、広報活動を通じて啓蒙、話題づくりを行う必要がある
と、氏はこんなふうに考えたのではないか。
炎上商売だと斬って捨てるのは簡単だが、私は今回の件を通じて、IT業界には技術者（労働者）と経営者の間に深い溝があるように感じた。
現実問題として技術だけでは金にはならない。多くの技術者は技術を金に換える手段を持っていないのだ。一方、IT企業の経営者は技術を金に換える仕組みを作ることが仕事だ。経営に関して考えなければならない課題は多く、単純に売り上げイコール技術の値段とはならない。そのあたりについて、経営者は技術者によく説明するべきだ。また、経営者も技術者へのリスペクトを忘れてはならないだろう。技術者と経営者はきちんと相互理解を深めるべきであるというのが私の考えだ。
説明を省略することは相手へのリスペクトを欠いた行為であり、両者の溝を深めるばかりだと思うのだ。
SDNのこれから
先日、ネットワークプログラマビリティ勉強会というところで発表をさせていただきました。そのとき、時間の都合で言えなかったことを補足しようかなと思い、久しぶりにブログ更新しますw
このスライドではあんまり触れてないんですが、まず最初のポイントはSDN(Openflow)って何でもできる技術なのに、なぜこういうソリューションにしようと思ったのか、ということです。
その話をする前に、参加できなかった4月度のssmjpでのスライドでグッと来たのがあったので紹介します。
このスライド（17ページ）にもあるように、結局ネットワークのOPEXって大したことないんです。ガンバレばできるのに、それをワザワザソフトウェアにする必要とかありますか、って話です。エンタープライズなんかで年に一回あるかないかの変更のためのコストを削減する意味はないです。テレビ局でのSDN導入事例はうまくニーズが合致した例ですが、かなりのレアケース。結局ソフトにするってことは動きが完全にわかってなきゃできない（やるべきでない）ので、OPEX削減のための手段としては筋悪だと思うのです。
じゃあ、SDNってどうやって使うべきなの？
参考になるのは他分野の事例です。航空機のフライバイワイヤというものをご存知でしょうか。
各種センサーの情報を元にコンピュータで航空機の翼をきめ細かく制御し、航空機の安定性を高める技術です。1秒間に数十回も翼を制御させることによって本来航空力学的に安定しない形状の航空機でも無理やり安定させて飛ばすことができます。これにより、高い運動性と飛行安定性という本来物理的に両立し得ない要素を両立させることができます。
「ソフトウェアで何かを制御する技術」とは、本来このように、人力では不可能なイノベーションを実現するためのものだと思うのです。
そのように考えた結果、10秒に1回経路を制御し、ネットワークのダウンをTCPの再送シーケンス内に収めることによって、結果的に切れないネットワークを実現することを思いつきました。この辺の使い方はアイデア勝負であり、私自身も試行錯誤中です。いくつかアイデアはあり、実際に作ってもいるのですが、まだまだ色々なことができると思っています。
この手のベストプラクティスがある程度そろって初めて、SDNは普及ステージに入っていくのかなと思います。
先は長い。。
