#NGK2014B でやるはずだったLT

まぁ、未稿だし

ごめんなさい。書き上げてないです。m(_ _)m
そもそも、書き始めたのが木曜日くらい。orz

コード、書いてないし

金融機関のCSVファイルと言えば、半角カナ混じりのsjisがデフォ。
半日くらい戦った挙句、伝統のnkf先生に丸投げしましたが。

N Network
K Kanji
F Filter

ですよ。間違っても、

N 何なの???
K こんなの!?
F 振っておけ(nkf先生にw)

ではありませんからww

どのみち

土下座コースなんですがねー。喜んで土下座しますよ!(キリッ

最底辺から送る目指せ最底辺の振り返り#-0.5

数時間のやっつけ仕事なんで

ハードウェアよりのことしか書いてないです。ゴメンナサイ。m(_ _)m

PDP-11とか教科書でしか見た事無いので

みんな知ってる(?)x86と対比して補足してみました。

"●●●でPerl"してみる

このときのスライドは?

どんな感じでしゃべったの?


なお、

あくまでも、昔話ネタのLTなので*1アジェンダとかまとめとか一切ありません。


そこの所、ご理解とご協力を強制します!

しかしながら、

せっかくじへい(@jihei)さんに撮影していただけたんだから、撮影者には真正面の特等席をご用意すべきだったと要反省。。。orz

*1:しかもネタバレ注意

UMLとクラウドのススメ

デスマっててずっとスライドのバグフィックスが出来なかったのですが、ようやく凡ミス修正とかアジェンダ&まとめとか出来ましたので、SP1版リリースです。

その前に以前会社で書いたコラム「今さら聞けないUML入門」で復習を

UMLって何なのさ?

Unified Modeling Language(統一化されたモデリングのための言語)です。
言語なんですがお絵描きするのが特徴で、構文・文法は覚えなくても大丈夫です。
但し、お絵描きには約束事があります。これが難しい。だからウサギレベルのもやもやした落書きからスタートするんですよ。

Unified(統一化された)ってどういう意味?

モデリング(モデル化)というアプローチはUML以前にもありました。
みんなバラバラの描き方をしてたのを統一したのでUnifiedです。統一化した恩恵で開発者同士のコミュニケーションが円滑になったり、
同じ絵を見てお客さんとお話しすることで要件定義がスムースに進むことが期待されます。

UMLには13年1ヶ月の歴史がある!

UML 1.0 仕様ドラフト版が1997年1月に公開され、その後2004年10月に2.0へのメジャーバージョンアップがありました。
2007年8月現在のバージョンは 2.1.1です。と言う訳で、それ以前にUMLのお勉強をして暫く離れていた人は涙目なんです。

UMLって難しそうだし、オブジェクト指向を使わない人には関係ない?

確かにクラスを作らない人には不要なものに感じられるかも知れません。
しかし、オブジェクト指向プログラミング(OOP)するか否かは実装の手段であってどのようなシステムでも要件定義は必要です。
設計者の頭の中で順不同に浮かんできたり顧客に仕様盛り込みをお願いされたりする要件を、
視覚的に整理して漏れを防ぐのにマインドマップが有効です。

じゃ、要件定義にマインドマップを使えばあとはOK?

マインドマップで列挙した機能でも、顧客の中で人事部の人と営業部の人では使う機能の範囲は違います。
共通して使う機能もあれば、人事部の人・営業部の人しか使わない機能もあるでしょう。
このような場合はユースケース図を描くとすっきりします。
共通して使う機能があれば、人事部と営業部の両方の要件を盛り込む必要があるので設計が大変になります。
予算の都合で全部盛りこめない場合もありえます。
ユースケース図を描く事でこういう危ないブロックを視覚化することができます。

マインドマップユースケース図で設計はOK?

OOPしなくても、ソフトウェアシステムには切っても切り離せないものがあります。それは、「シーケンス」と「状態」です。

シーケンスって何なんだ?

シーケンスとは、ソフトウェアのシステムの機能が実行される流れです。
機能の単位は関数・メソッドの場合もあれば、スレッド・プロセスの場合や、
他サーバのDBやクレジットカード会社のホストなど別の計算機である場合もあります。
UMLでシーケンスを描くにはシーケンス図を使います(そのまんまだ)。
例としてAmazonで本を注文することを考え、ログインのシーケンスを妄想してシーケンス図を描いてみました

状態って何なんだ?

ソフトウェアのシステムでは、ネットワーク的に離れた通信相手やデータベース検索や銀行ATMの入金取引での紙幣計数など、
他の要素に作業を依頼して完了を待つ時間帯が存在します。この時間帯の種類を状態と言います。
ある状態から別の状態へ変化することを状態遷移と言います。
状態遷移のきっかけ(トリガー)は、別の要素からの作業依頼受信&作業結果送信や、
他の要素への作業依頼送信&作業結果受信であることが一般的でイベントと呼びます。
UMLでは状態遷移を表すのにステートマシーン図(状態遷移図)を描きます。
同じくAmazonで本を注文することを考え、ステートマシーン図(状態遷移図)を描いてみました。

さて、肝心のLTだが

@katzuenoさんが撮影&Ustreamで放送してくれたので、ありがたくrecordedな動画から自分の分を切り出して、YouTubeにアップロードしておきましたので、ご覧ください。#激しく焦りまくりだけどね。orz


で、激しく引っ張りすぎですが

肝心のバグフィックスSP1版のスライドはこちらです↓

いちおう、ブログでも纏めとく

UMLはいろいろ約束事があって取っ付きにくいが、


①最初は「うしのモヤモヤしたラク書き」レベルでいいから、書いておけ!
②ChangeVisionさまのastah* communityで描いておけ!1時間も使えばなんとなく判る!
Microsoft Office Visioの生産性は(ry
てなところだww

貧乏人のための仮想化tips

総花的な感じで内容が薄いかなーと思っていましたが、意外と評判が良かったです。
当日の昼休みの段階でテキストファイルでしかなく、定時後にスライドにしたのでページ重複やtypoでボロボロなのはここだけのヒミツ。

LTの概要

  1. プラットフォームはホスト/ゲストとも軽いのにしておけ!
  2. 必要なものしかインストールするな!(特にゲストOS)
  3. ゲストOSのデータはブート仮想ディスクに入れるな!データ用の仮想ディスクに入れておけ!VMをコピーするとき涙目だぞ!
  4. データは仮想化しない方がメリット大!(NFS, SMB, NAS, SANなど)

つまるところ

OS環境を仮想化することで、環境の構築・複製・破棄が簡単になるのはその通りなんですが、データを仮想化する必要はないということです*1

次回はこの方向でもちっと掘り下げて話せるといーな。

*1:ディスクI/Oの仮想化はわざわざIntelがVT-dを開発してハードウェアでアシストする必要があるほどコストが高い