2016年7月26日火曜日

JTF2016 にて(なぜか)孫子の話をしてきました


このエントリーをはてなブックマークに追加


July Tech Festa 2016 にて『今エンジニアに最も必要なものは「戦略」である!孫子に学ぶ本質のつかみ方』と題して発表させていただきました。

Tech Festaなのに戦略?孫子??と思われる方もいるかもしれません(私もそう思わないでもありません)が、実はエンジニアにこそ「戦略」は重要なのです。
激変しつつあるIT業界で働く方には、何となく自分の取り組みにモヤモヤしたものを持っている方も多かったのか、予想外に多くの方に聞いていただけて大変うれしかったです。

発表に使った資料はこちら(詰め込みすぎて後半の時間が足りませんでした)


本発表で参考にした書籍からおすすめを紹介します。

戦略・戦術の解説のために使った「戦略の階層」はこちらの書籍に詳しく書かれています。


「芸の絶対化」の危険性など、先の大戦から日本人が陥りやすい失敗・思い込みなどがこちらで解説されています。


「エレベーターの待ち時間問題」の抜粋元です。名著ですが既に絶版です。図書館や工学系大学の図書館で読むことができます。


そして孫子です。孫子は解説含めてもかなり短い本ですので、ぜひ一読してみてください。その前に、一度「戦略」について理解していると、より深く孫子が理解出来ると思います。



ぜひ、自分なりの戦略を立ててみてください。


2016年6月26日日曜日

OpenStack/Heatによるオーケストレーション入門


このエントリーをはてなブックマークに追加


OpenStackユーザ会の第28回勉強会のネタです。


前回の完全版のネタになります。このネタは私が大学で担当している講義資料から抜粋しています(ほとんどそのまま

演習つきなので、興味があれば以下を見ながら試してみてください。
https://etherpad.openstack.org/p/r.16d9199da6f662084a2362e58d6d18e5


今回の勉強会の中で、実環境でHeatを使う際のいくつかの注意事項を述べたのでまとめておきます。

Heat「だけ」で全部やらない

これにつきます。
HeatはOpenStack上のリソースを配置、操作するだけならば他のツールに比べても優れています。記法はシンプルで操作方法もかなり単純です。しかし、OpenStackの外にあるものや、OpenStack上に作成されたインスタンス中を操作しようとすると途端に難易度が上がってきます(頑張ればできなくはない)

一昔前であれば、学習コスト等を謳い文句にして、1つのツールを徹底的に使いこなして細かな末端までカバーするのが良い、という宣伝がされていましたが、現在はこういうアプローチはあまりされません。
そのツールが得意なことだけをそのツールにやらせて、足りない部分はそこが得意な別のツールでカバーする、「ツールチェイン」のアプローチが一般的になってきています。

例えばOpenStack上のリソースを作成するのにはHeatを使い、作成されたインスタンスの設定はAnsibleで行う、といったようなやり方です。
Ansibleは汎用的な環境化で手順を自動化することが可能ですので、OpenStack上のリソースを作成して、そのリソースの起動を保証するといった事も出来なくはないのですが、やや複雑なプレイブックを書く必要が出てきます。
そこで、得意なリソースの作成と保証の部分をHeatにまかせて、Heatが作成したスタックの外部出力値を、Ansibleのダイナミックインベトリへ渡すといったやり方をすることで、結果として全体をシンプルにすることが可能になるのです。

ここではHeat + Ansibleの例をあげていますが、他の場合でも同様です。
皆様も自分の環境に合わせて、最適なツールチェーンを模索してみましょう。


2016年2月15日月曜日

CLML.LAPACK-ENVIRONMENT::DYNAMIC-HEAP-SPACE-TOO-SMALL


このエントリーをはてなブックマークに追加


SBCLで機械学習パッケージのCLMLを導入しようとすると、以下のエラーが出る場合があります。
When you try to install CLML on SBCL, you might encounter the blow problem.

COMMON-LISP:SIMPLE-TYPE-ERROR : CLML.LAPACK-ENVIRONMENT::DYNAMIC-HEAP-SPACE-TOO-SMALL does not designate a condition class.

この理由は実行環境のメモリ不足です。
This reason is too small memory size of lisp execution environment.

以下で解決できます。
The solution is below:

$ sbcl --dynamic-space-size 4gb

デフォルトでSBCLは1GBです。これは、CLMLをコンパイルするには少なすぎます。
Default SBCL memory size is 1gb . It's too small to compile CLML on SBCL.


2016年1月12日火曜日

ThinkPad X1 Carbon Gen3 + Fedora23


このエントリーをはてなブックマークに追加


こんな記事を書いたのに、またThinkPadを買ってしまった・・・。米沢産なので安心?(●`ε´●)
実際、今回のThinkPadはほとんどトラブルは無いです。実はもう半年くらい使ってます。



ということで、X1 Carbon Gen3 をFedoraで使ってみた感想。



2015年12月24日木曜日

Hot の書き方(前編)


このエントリーをはてなブックマークに追加


OpenStack Advent Calendar 2015 ネタ。

ホントはHotでマルチノードOpenStack環境を作るところまで解説したかったのですが、HOTが巨大になりすぎて解説までかけませんでした。
続きはそのうちもう少し練り込んだHOTと合わせて追記して公開します。

ということで、今回はHeatテンプレート(通称HOT)の基本部分の解説をました。

それではみなさん、良いお年を。


2015年11月14日土曜日

中央区のいいプロバイダないですか


このエントリーをはてなブックマークに追加


ここ半年くらい回線が遅過ぎて困ってます。
平日の夜、土日祝日はこんなスピードしか出ません。
------ BNRスピードテスト (ダウンロード速度) ------
測定サイト: http://www.musen-lan.com/speed/ Ver5.6001
測定日時: 2015/11/14 21:25:02
回線/ISP/地域: 
--------------------------------------------------
1.NTTPC(WebARENA)1: 112.08Kbps (13.88KB/sec)
2.NTTPC(WebARENA)2: 143.83Kbps (17.97KB/sec)
推定転送速度: 143.83Kbps (17.97KB/sec)
------ BNRスピードテスト (ダウンロード速度) ------
測定サイト: http://www.musen-lan.com/speed/ Ver5.6001
測定日時: 2015/11/14 21:44:14
回線/ISP/地域: 
--------------------------------------------------
1.NTTPC(WebARENA)1: 112.26Kbps (14.02KB/sec)
2.NTTPC(WebARENA)2: 174.18Kbps (21.65KB/sec)
推定転送速度: 174.18Kbps (21.65KB/sec)

pingも頻繁に応答がなくなり、15年前に東北で引いてたケーブルTVがやってたネットより遅いし安定しません。
動画見れば再生に追いつかず頻繁にロード待ちになり、ネトゲは常時ラグラグでまともに遊べない。
迂闊に容量大きめのiOSアプリをアップデートすると、1,2時間は終わりません。

朝方は40MB/secくらい出ているので機器の故障ということはないとは思います。
実ははじめは機器の故障かと思って壊れてもいないA-Termを最新型に買い換えてしまいました。

もし東京の中央区・江東区でおすすめのプロバイダあれば教えて下さい。
今は光のマンションタイプです。


Open vSwitch ブリッジインターフェースのMACアドレスを固定する


このエントリーをはてなブックマークに追加


久々に更新です。ネタはあるのですが忙しくてなかなかアウトプットできてませんでした。

タイトルの通り、Open vSwitch で作成するブリッジのMACアドレスを固定化します。通常はOVSが適当に割り当てます。
インターフェース作成後に、以下の感じでデバイスと与えたいMACアドレスを指定します。

$ ovs-vsctl set bridge br-ex other-config:hwaddr=92:c3:28:4c:09:45

これはOpenStack上のインスタンスでいろいろ実験したい時に便利です。

通常OpenStackのNeutronの論理ポートは接続先の仮想マシンに割り当てたIPアドレスとMACアドレス以外の通信を許可しません。そのためブリッジデバイスやらをインスタンス上で作ってもそのままでは通信することができません。

そこで、このコマンドでMACを固定化した上で、Neutronの allowed-address-pairs という機能を使い以下のように、論理ポートに対して特定のIP/MACの組み合わせを許可する設定を入れ込むことで、かなり自由な通信を行うことが可能になります。


特定IP指定や、
$ neutron port-update $PORTID00 \
  --allowed-address-pairs type=dict list=true mac_address=fa:16:3e:0c:6d:89,ip_address=172.16.100.99


CIDR指定が可能です。
neutron port-update $PORTID00 \
  --allowed-address-pairs type=dict list=true mac_address=fa:16:3e:0c:6d:89,ip_address=172.16.100.0/24


2014年12月25日木曜日

OpenStack/CloudStack/Eucalyptusが教えてくれること


このエントリーをはてなブックマークに追加


今年最後のカレンダーネタです。
http://www.adventar.org/calendars/602
http://www.adventar.org/calendars/547


OpenStackやCloudStack、Eucalyptusといった、いわゆるクラウド基盤ソフトウェアを技術的に学習することで得られるものは多々あります。

ビジネス的には、自社のサービス基盤の効率化への活用だったり、SIビジネスを展開する材料にしたりできます。これらを習得する過程で、基礎的なLinux/Unixに関する技術も習得できるようになるため、エンジニアとって有用な教材であるといえます。さらに、構築したクラウド基盤上でどのようにシステムを構築し、運用するのか、という視点を持つことで、従来とは異なった、「クラウドネイティブ」なシステムデザインしていくきっかけにもなるとも思います。

このように様々なことが学習できる優秀な教材でもあるクラウド基盤ソフトウェアでありますが、中でも抑えておくべきポイントとして「抽象化」の考え方があります。


抽象化(ちゅうしょうか、英: Abstraction、独: Abstraktion)とは、思考における手法のひとつで、対象から注目すべき要素を重点的に抜き出して他は無視する方法である。反対に、ある要素を特に抜き出して、これを無視したり、切り捨てる意味もあり、この用法については捨象するという。従って、抽象と捨象は盾の両面といえる。
Wikipedia より

この観点でこちらに記事を書きました。
http://www.atmarkit.co.jp/ait/articles/1412/12/news016.html

その他の関連記事はこちら(宣伝)
http://www.atmarkit.co.jp/ait/subtop/features/kwd/openstack.html

OpenStackやEucalyptus、そしてCloudStackは多岐にわたるITインフラ(サーバー、ネットワーク、ストレージ)を抽象化し、より大量の計算リソースを素早く、簡単に扱えるようにしてくれます。

この流れは計算機の正当な進化に沿ったものであると言えます。計算機の世界は抽象化の層を積み重ね今日に至っており、OpenStackはその抽象化の層をまた1つ追加しようとしています。そして計算機のビジネスは抽象化の一番外側にいる層が現実世界との接点となり、ビジネスが発生するポイントになります。だからこそ、多くのITベンダーがOpenStackに注目し、こぞって開発に参画し、次世代のビジネスを主導権を取ろうと勝負しています。

クラウド基盤ソフトウェアを学習するとき、あるいはビジネスでの活用を検討するときには、この抽象化の意味を良く考える必要があります。一体、何のためにこの層が必要だったのか?この意味を考え、理解すれば自ずと、クラウド基盤ソフトウェアの正しい活用方法というものがわかるはずです。



来年から大学でクラウド基盤ソフトウェアに関する講義を持つ予定ですが、学生の皆様には表層的な「使い方」ではなく、こういった計算機の本質的な考え方を伝えていければと考えています。

それではまた来年もよろしくお願いします。


2014年12月21日日曜日

民明書房刊「クラウドの歴史」より


このエントリーをはてなブックマークに追加


今日は皆様に我が国における、クラウドの歴史について少し紹介させてください。

おぷすたや
あゝおぷすたや
おぷすたや

この句は、江戸時代中期に詠まれたものであると伝えられている。
信越地方の藩主の嫡男が、出島で見かけた”おぷすた”なるものに心を奪われ、思わず口にしてしまったものを偶然に通りかかった魚拓職人が記録し、現代に至る。

それまでは幕府の定めた”くらうど”しか使えなかった諸藩は、このおぷすたに大変な関心を示し、皆がこぞって利用するようになった。
幕府のくらうどは、”くらうど”といいながら、利用するには専門の職人が要求書を書面で送る必要があり、実際に使えるようになるまで、1周間以上待たねばならず、時には1ヶ月以上も待たされる時もあったという。

このような状況に不満が蓄積されていた背景もあり、おぷすたは国内で爆発的に普及した。
ただ利用するだけではなく、足りない機能をみんなで開発し、いかに自分の藩が素晴らしい貢献をするかを競い合い、いつしか貢献度に応じて藩の格付けまでされるようになった。
また、当時は通信手段も乏しく、隣の藩と連絡を取るために街道の整備が急速に進み、これが後の東海道となり、日ノ本の経済を活性化させる要因ともなっていく。

しかし、この状況を面白くないと思った幕府は、禁おぷすた令を発して、諸藩のおぷすたへの取り組みを禁止した。
後の世に言う、「仮想環境憐れみの令」である。

曰く

・仮想マシンはペットのように可愛がらねばならん。
・それにオープンソースなどサポートがなくて使えない
・もし何かあったら誰が保証するんだ

というのが幕府の言い分であった。
当然、多くの人がこの考え方に反発した。中でも強硬に反発したのが大塩平蜂郎であった。大塩は元幕府の役人であったが、幕府のくらうどに対する考え方が我慢できず出奔した経緯を持つ。大塩は幕府に対して、

「1時間後に仮想環境を100台用意しろ」
「俺が寝ているときに負荷が上がったら、勝手に仮想環境を増強しろ」

などと無理難題を要求した。当然これに対応できない幕府は要求を無視するが、これに怒った大塩によって引き起こされたのが有名な「大塩平蜂郎の乱」であるのはあまりにも有名である。

この後も、幕府はなんとかおぷすたの勢力を抑えこもうとするが、一度広がったおぷすたの考え方は市場に浸透し、既に国内から一掃するのは不可能であった。幕府内にも反発する勢力が日に日に増大し、最後には幕府が折れることで、一連の騒動は幕を閉じる。

そしてその後、誰もが自由に使えるおぷすたは大いに広がり、江戸後期には様々なコンテンツビジネスがおぷすた上で展開され、江戸の住民を多いに楽しませたという。














ちなみに全部フィクションであることは言うまでもない( http://www.adventar.org/calendars/602 )


2014年12月11日木曜日

Emacsでプレゼン資料を作る(landslide)


このエントリーをはてなブックマークに追加


OpenStack Advent Calendar 2014 のネタです。
http://www.adventar.org/calendars/569
http://www.adventar.org/calendars/602

なんでEmacsなんだよ、と思われる方もいると思います。まずは話を聞いてください。

OpenStack には Upstream Training というコントリビューターを育成するプログラムがあります。これまで、グローバルで3回開催されています。

1回目 OpenStack Summit Atlanta
2回目 Upstream Training Japan
3回目 OpenStack Summit Paris

今後の予定は、たぶんこんな感じになると思います。

4回目 OpenStack Days Tokyo 2015(予定)
5回目 OpenStack Summit Vancouver(予定)
6回目 OpenStack Summit Tokyo(予定)

実は、世界でこのトレーニングを受けることができるのは、Summitに参加した人か、日本に住んでいる人だけになります。日本のトレーニングはローカライズもされています。貴重ですね。


と、これは本題ではなく、このトレーニングで使われている教材が、githubに公開されています。
https://github.com/openstack/training-guides/tree/master/doc/upstream-training

スライドの実態はこのあたりです。テキストファイルです。
https://github.com/openstack/training-guides/blob/master/doc/upstream-training/01-release-cycle.rst

このテキストファイルを landslide というツールに食べさせると、HTML5のプレゼンファイルができます。
https://github.com/adamzap/landslide


という事で、Okinawa OpenDays 2014 で開催される、OpenStackハンズオンの資料をlandslideで作ってみました。
http://irixjp.github.io/20141212_okinawa/handson.html/


landslide を使ってみた感想をまとめます。

・Emacsで資料を書ける(Markdown or rst形式)
・テキストベースのスライドなら使いやすい
・画像を交えると結構苦しい
・印刷がかなり難しい、PDF変換も綺麗にはいかない(今は)
・CSSに詳しくないと、カスタマイズが難しい。
・レイアウトが環境によってずれる(Win/Mac/Linux/ブラウザ)


と、一長一短かなと思いました。
一方で、これにブログ記事をスライド形式で書くのも面白いと思いました。


ちなみに、S式でプレゼンを書くツールもあります。
https://github.com/fukamachi/L5

Emacs org-mode をプレゼン風に使うelもあります。
http://pastelwill.jp/wiki/doku.php?id=emacs:org-tree-slide


PPT/KEYにはもう飽きたよ、という方は次のOpenStack勉強で使ってみてください(保証もヘルプもしませんが)

それでは良いお年を。