vFabricという製品群について学習を進めることにします。
この製品群は、Infrastructureの上へ位置する製品群です。
日本語でいうところのミドルウェアという言い方でしょうか。
個人的にはミドルウェアという言い方は、好きではありません。
なぜならミドルウェアがあると言うことは、アッパーウェアやアンダーウェアがあるということですので。。
世の中を見回しても、ITと下着が混在するとは言語道断(。・ω・。)
まぁ個人的な見解ですので、あまり気になさらずに(..;)
さてさて、eラーニングは便利ですね。
vFabricは英語のeラーニングで提供されているため、英語の勉強になります。
案外IT業界の用語は、そのまま日本語化されているので英語もよく聞き取れます。
英語の勉強も兼ねて学習をすることにします(*^O^*)
2012年5月24日木曜日
2012年5月22日火曜日
VSP5合格
当面の目標であったVSP5に合格しました。
面目躍如(゚_゚;)
残るはVCP5やな(..;)
負荷にならない程度に頑張ります(´д`)
今日は雨が降って、足下が悪いですね。
体調管理に気をつけましょう(゚▽゚*)
面目躍如(゚_゚;)
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
残るはVCP5やな(..;)
負荷にならない程度に頑張ります(´д`)
今日は雨が降って、足下が悪いですね。
体調管理に気をつけましょう(゚▽゚*)
2012年5月21日月曜日
2012年5月20日日曜日
VTSP合格
技術者の宿命か。。。
VSPは案外引っかけ問題があるような気がする(ノД`)
VTSPは無事受かりました(。・ω・。)
よかったよかった。。
問題はVSPやな。。
明日には受かるでしょう。きっと(;゚ロ゚)
eラーニング
急速立ち上げです。
久々にプログラムから解放されて、暗記物のお勉強をしております。
この生活もそろそろ終わりを迎えるのかな(ノД`)
そうおもうと寂しい気もします。
なかなか集中力が続かなかったので、途中自転車で秋葉原へ。
秋葉原でthunderboltのケーブルを買うのをすっかり忘れていました。
気分転換にはなったけど、目的のモノを買い忘れるとか。。。(;゚ロ゚)
まぁまだ時間はありますので、また今度買いに行こうっ(*^O^*)
本日の成績
VSP5(9/10)
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
残り1つでVMware Sales Professionalがとれそうです。
営業の単語は、馴染みが薄いので案外大変です。
残り1つなので、じっくり取得していきたい。
VTSP5(2/6)
| |
| |
| |
| |
| |
|
3つめでバグが発生してとりあえず中断。
4つめはバグがないと思いきや、同様のバグが発生したため中断。
VMware Technical Sales Professional という技術の最初の資格。
明日には両方の資格が取れれば良いなと(゚_゚)
そしてVCPへ進んでいきたいと思います。
思うのは、vmwareさんととある会社は共に外資なのですが(^_^;)
こうして、vmwareさんの方は情報が開示されているのはうれしいですね。
裏も表もない信用に足る企業だと思います。
努力が定量的に計れるので、第三者から見てもよく理解度が深まります。
企業を比較できるので、がらっくは恵まれているなと個人的には思います。
とある画像メーカは、資料がないため、信憑性に欠けます。
情報が欠けているため、本質を得るのに非常に時間がかかります。
すべての製品に筋が通っていないんですね。。
eラーニングもあることはあるのですが、製品間の基本的な動作が全く異なるので、同じ会社の製品かと疑ってしまいます。
それよりも画像処理の基本的な概要を教え込めばいいのに(゚_゚;)
ある程度、基本的なパターンを教育すれば良いと思いますが、自分の技術を教えたらお払い箱という概念が強いのか。
まぁ、仕方がないのかもしれませんね。
結果としては、裾野が広がらないので、市場は閉じていくだけですね。
新しい人に伝えないと、裾野は広がらないので、すでに画像メーカは詰んでいる気がいたします。
例えて言うと
出血しているところにとりあえずガーゼを当てて、そのままにしている感じがします。
出血の原因は、切り傷なのか擦り傷なのか、打撲なのか骨が見えているのか等の原因追求をした方が良いと思いますね。
ガーゼを代えるように、人を入れ替えてもそのうち失血死すると思います(´д`)
まぁ、失血死して被害を被るのは結局画像メーカの人たちなのですけどね。。
将来を見ていませんよね。
将来どうなるか。
落としどころが全く見えていないのか。
見ようとしていないのか。
まるで他人事のような気がします。
まぁ、火の粉は払いながら自分の考えで進めないと巻き添えくらっちゃいますよね(゚▽゚*)
2012年5月19日土曜日
お勉強
がらっくです。
久々に仮想化についてお勉強をしております。
勉強をしようとした背景としては、次の通りです。
画像処理について記載しております。
・利益率があまりよろしくない点
機器単品売りでは、薄利になります。
薄利ですと、数をはかなければなりません。
また、機器の値段は、年々下がっていく一方です。
・製品にバグが多すぎる点
製品に内在するバグが少なければ、数を捌けると思いますが、バグも1年や2年放置しっぱなしです。
・バグに伴って不慮の対応が多くなる点
不慮の対応が多いと、対応のみで新しい仕事が行えません。
手間がかかるため、仕事において良い評価にはつながりません。
・経験ビジネスだから新規参入は難しい点
経験が大事なビジネスとの側面が強いのです。
経験年数が高いからよく売れるとは一概には言えません。
なぜならば、競合会社は若い人たちが販売して成功していますので経験ビジネスだからという側面で捉えるのはどうなのかなと。
上記から導き出されるのは、自分たちが経験したことを、若い世代に伝えていない事が事の本質かと思います。
・経験をすればそれなりに上達すると思っている点
ある側面は正しいのですが、上達をするにしても利益幅が良い形に教育をすることがボリュームにつながると思います。
利益幅が大きいように教育する事を放棄しているため、今後の見込みはありません。
結論からしては、画像処理に対してすべてのリソースをかけるのはあまり得策ではないなと(´д`)
個人的に思います。
画像処理3
仮想化7の割合が良い気がいたします。
そこで、昔取った杵柄で仮想化について再度学習しようかと思いました。
戻ったときのことを考えて、ある程度リハビリが必要ですので(*^O^*)
時既に遅し感が否めませんが、とりあえず画像処理よりも母分数は多いですので。。
eラーニングを受講していますが、以前と比べて大幅に機能が追加されていますね(゚_゚;)
ver3からver5への機能追加は、真新しいモノに映ります。
おもしろいのは、End User目線でITの資源を活用でき点が良い兆候かなと思いました。
IT部門は、お荷物なイメージしかないのを払拭できる良い機会だと思いますね。
本来は仕事をよくするためのツールとしてITを活用する事が求められていましたが、今は、機械に使われている感が否めません。
本来の目的で使われるようになればと思います。
2012年5月17日木曜日
プログラム
がらっくです。
おおむね開発は滞りなく進んだのですが、全体を通して感じた事柄を書いていこうと思う。
背景から
プログラムを開発する際に、工数という概念があります。
工数は多いほど、複雑なプログラムで構築されています。
工数が多いほど、コストは高額な傾向があります。
高額な商品は、時として顧客には受け入れがたい事になります。
そこで、工数を減らす努力が行われます。
工数を減らす事柄としては、複数の方法が考えられています。
代表的な例は次の通り。
1. 部品化
これまでのプログラム開発で培ったノウハウを部品化する。
似たような事柄であれば、古いノウハウを使用できる場合がありますが、往々にして部品化して工数が減ったと言うことは聞いたことがありません。
2. 開発環境の改善
メーカ側のお話ですが、開発環境を良くすることにより開発工数を減らすといったことも期待できます。
3. 背に腹は代えられない場合
明日運転資金を得るために、背に腹は代えられない状況で受注する事があります。
こういった状況ではプログラマはあまり良い成績を収めることはできません。
まぁあまり感心はしない事柄が多いですね。
上記の理由から、プログラムが良くて評価されることは滅多にありません。
そもそも発想がマイナスからスタートですので。
と大幅なけちをつけても話が始まらないので。。
開発環境から見る開発の一連の流れを見てみることにしてみましょう。
今回開発を行った言語は、C#でした。
ある程度Cを触ったことのある人であれば、理解しやすい言語です。
VisualStudioで簡単にさくさく書くことが可能ですので、非常に工数としては削減されていたと錯覚いたします。
ここで記述した錯覚というのは、あまりにも書きやすいがための例外処理が疎かになるということです。
テストケースを作成しながら書けばいいのではと思うのですが、書いている最中に結果を予測しながらはプログラムを書くことは困難です。
なおさら、初心者になればなるほどそれは困難に近い形です。
何を言いたいかというと、プログラムの初期の工数は削減できるが、簡単に書けるために、エラーを見逃しやすい事が発生しているという事です。
逆に言うと、プログラムの工数は多いが、プログラムは厳密に書かないとエラーが発生しないと言うことです。
上記2つは、同一のことを指していますが、落とし穴でもあります。
工数の観点から見ると、初期の工数が削減できた方が仕事が取りやすい形になります。
要は、初期の工数が減る方が有利だと言うことです。
仕事は、初期の費用を回収すれば終わりですから、運用に関してはあまり金額を払いません。
プログラムのバグがそのまま放置されたまま運用に突入してしまう形になります。
運用時にお金を払う顧客は、滅多にいません。
運用時にトラブルが発生すると、導入業者に連絡することになります。
つまり、プログラムが滞りなく順調に動く事を念頭に考えると、運用においてもある程の費用をもらうことが、プログラムをかくうえで必須な事柄になります。
とここで書いても、顧客側は、お金を払う事は避けたがるので、このギャップを埋める営業がいればプログラマも救われるのですが、なかなかいませんよね(*^O^*)
顧客にとっても、プログラマにとっても不幸なのは、システムが良い方向を向かない原因でもあります。
顧客は、お金を払いたくない。
プログラマは、ただ働き。
そういった動機から、モチベーションは下がっていくのだと思います。
構造的に弱点を持っているために、プログラム開発会社は、初期費用が枯渇すると全滅する性質を持ちます。
逆に言うと、初期費用を調達できる体力があれば、免れるという形ですね。
まぁ、プログラムは全世界共通ですので、日本で優位性が保たれないと、人件費が安い人たちに取って代わられますね(゚_゚;)
おおむね開発は滞りなく進んだのですが、全体を通して感じた事柄を書いていこうと思う。
背景から
プログラムを開発する際に、工数という概念があります。
工数は多いほど、複雑なプログラムで構築されています。
工数が多いほど、コストは高額な傾向があります。
高額な商品は、時として顧客には受け入れがたい事になります。
そこで、工数を減らす努力が行われます。
工数を減らす事柄としては、複数の方法が考えられています。
代表的な例は次の通り。
1. 部品化
これまでのプログラム開発で培ったノウハウを部品化する。
似たような事柄であれば、古いノウハウを使用できる場合がありますが、往々にして部品化して工数が減ったと言うことは聞いたことがありません。
2. 開発環境の改善
メーカ側のお話ですが、開発環境を良くすることにより開発工数を減らすといったことも期待できます。
3. 背に腹は代えられない場合
明日運転資金を得るために、背に腹は代えられない状況で受注する事があります。
こういった状況ではプログラマはあまり良い成績を収めることはできません。
まぁあまり感心はしない事柄が多いですね。
上記の理由から、プログラムが良くて評価されることは滅多にありません。
そもそも発想がマイナスからスタートですので。
と大幅なけちをつけても話が始まらないので。。
開発環境から見る開発の一連の流れを見てみることにしてみましょう。
今回開発を行った言語は、C#でした。
ある程度Cを触ったことのある人であれば、理解しやすい言語です。
VisualStudioで簡単にさくさく書くことが可能ですので、非常に工数としては削減されていたと錯覚いたします。
ここで記述した錯覚というのは、あまりにも書きやすいがための例外処理が疎かになるということです。
テストケースを作成しながら書けばいいのではと思うのですが、書いている最中に結果を予測しながらはプログラムを書くことは困難です。
なおさら、初心者になればなるほどそれは困難に近い形です。
何を言いたいかというと、プログラムの初期の工数は削減できるが、簡単に書けるために、エラーを見逃しやすい事が発生しているという事です。
逆に言うと、プログラムの工数は多いが、プログラムは厳密に書かないとエラーが発生しないと言うことです。
上記2つは、同一のことを指していますが、落とし穴でもあります。
工数の観点から見ると、初期の工数が削減できた方が仕事が取りやすい形になります。
要は、初期の工数が減る方が有利だと言うことです。
仕事は、初期の費用を回収すれば終わりですから、運用に関してはあまり金額を払いません。
プログラムのバグがそのまま放置されたまま運用に突入してしまう形になります。
運用時にお金を払う顧客は、滅多にいません。
運用時にトラブルが発生すると、導入業者に連絡することになります。
つまり、プログラムが滞りなく順調に動く事を念頭に考えると、運用においてもある程の費用をもらうことが、プログラムをかくうえで必須な事柄になります。
とここで書いても、顧客側は、お金を払う事は避けたがるので、このギャップを埋める営業がいればプログラマも救われるのですが、なかなかいませんよね(*^O^*)
顧客にとっても、プログラマにとっても不幸なのは、システムが良い方向を向かない原因でもあります。
顧客は、お金を払いたくない。
プログラマは、ただ働き。
そういった動機から、モチベーションは下がっていくのだと思います。
構造的に弱点を持っているために、プログラム開発会社は、初期費用が枯渇すると全滅する性質を持ちます。
逆に言うと、初期費用を調達できる体力があれば、免れるという形ですね。
まぁ、プログラムは全世界共通ですので、日本で優位性が保たれないと、人件費が安い人たちに取って代わられますね(゚_゚;)
2012年5月16日水曜日
久々の更新
がらっくです。
またもや久々に更新です。
とりあえず、1プロジェクト終わりましたー(ノД`)
しんどかったーおかげで若干風邪気味...
今は何もしたくない。。。
温泉に入りたい。そんな感じです。
さて何から話をしていこう。
時系列になっていませんが、とりあえず書いてみよう。
とあるプロジェクトのお話。
GW前から忙しくなり始め、GW後から大変に(´д`)
またもや久々に更新です。
とりあえず、1プロジェクト終わりましたー(ノД`)
しんどかったーおかげで若干風邪気味...
今は何もしたくない。。。
温泉に入りたい。そんな感じです。
さて何から話をしていこう。
時系列になっていませんが、とりあえず書いてみよう。
とあるプロジェクトのお話。
GW前から忙しくなり始め、GW後から大変に(´д`)
ゴールの設定が不明なために、ゴールが見えないまま全力ダッシュをしている感覚に。
だんだんとやる気が無くなっていく自分に周りからいちゃもんをつけられるという自体に(..;)
あまり、気にしないでおこう(。・ω・。)
とりあえず、自分の箇所は終わったのでこれにてプロジェクト終了!
4ヶ月でした。長かったです。
プログラミングは、概要のみを作成するだけで、実際のプログラミングは専門家に任せるほうがいいですね。。。
プログラミングについても、次回ブログで書いてみようと思います。
さて、来週は、トラブっている製品について学習をしていきます。
月末には名古屋で説明員なので、ある程度話せるようにしないといけない。
その後は、資料等も無い別のプロジェクトに入る予定です。
資料を整備しないとね(´д`)
メーカなのに資料がないとか。良い会社ですねぃ。。
登録:
コメント (Atom)
