良き1年なり

今年は足の骨折があったがすべて順調に動く。
理想的な1年でもある。
2年越しの疲れも解消されようとしている。

2013年、大きく飛躍の年となる。
ある計画も着々と進行中。

2012年はこれにて終了。
みなさん、良き新年をお迎えください。

仕事おさめ

27日が仕事納め。
といって、いろいろなことをしているので、Zendを利用したサーバーの試験運用とアンドロイドのアプリを制作中。
楽しみは年末年始、食べて飲みながら、アプリを作ります(爆笑)

27日に東京駅に、建物の建設中が多く、皇居から東京タワーが見えないことが多くなった。以前はよく見えたのに・・・
都心は建設ラッシュが続きます・・・

PCの再設定

26日に久々にPCを再設定。

音声がでないのはRealtakの初期が音声オフだったからだ。
いままでに気がつかず、音声がでないものと思っていたほど。
これいは驚いた・・・

EclipseやMySQL、Javaのバージョンアップ、アンドロイドの開発環境をすべて更新。
古いものは削除し、6時間以上かけて、最新に変更。
設定もさまざまであったが、最新バージョンに対応できるようになってほっとする。

Eclipseは3.7
Javaは7.10
Mysqlは5.5
アンドロイドは4.2
PHPなどは5.4にする

設定ファイルなどが変わるので、苦労することがありますが、成功してしまうとすぐ忘れそう。

技術は常に進歩する

技術は常に進歩する。
やり方も変わる。このような時代での学び方はどうすればよいのでしょうか？

学ぶ時、基礎からすべてが必要なことがあります。
しかし、すべてを学ぶ時間はありません。
IT技術の進歩は常に変わります。
最初はわからないことがありますが、先輩や先人のまねををし、取得することが必要。
そこから、基礎となるところ、また変わらない基礎があります。
そこをしっかり学ぶことが必要。

Javaの世界は変わりましたが、基礎となるものはC言語、C++言語です。
そこには先人達が苦労したことを簡単化させています。

Web社会になり、WebとJavaとの結合となるとき、
徐々にWebブラウザ側も進化し、サーバ側も進化しています。
今日Javaの世界でも
　ブラウザ側　HTML5、WEB-APIの進化
　サーバ側　　メッセージ機能の強化、進化しています。

このような世界です。利便性がどこにあるのかを技術者が考えるとき、
初心者がいかにITが使えるのかを考えてください。

技術が使用すると考えてはいけません。謙虚な気持ちで技術を取得してください。

2013年の展望

2013年の展望
①政治については夏の参議院選が大きな山場。今後の日本の方向性が決まる。
　政治に頼らない社会⇒失望か政治を考えない社会になるか・・・
　どちらにしても、若い人の失望感や、小さな子供を抱える家庭には不満の社会になりそう。
②企業と人
　大企業がどう動くかによって社会も変わりそう。
　⇒即戦力は存在しないことを自覚すべき
　⇒人を育てることは不可能を自覚
　⇒基本を知って応用できる人を採用すべき
　⇒中小企業はアイデアを活用し、販路および技術力を確保
　⇒日本語だけではなく、英語、中国語などが話せるようにすること
　⇒学習できる環境を持つものが重要になる

2012年特集-2

2012年は経済的には疲弊気味。
勝ち組負け組と分けられる人もいますが、実際勝ち組といっても、負け組に等しい。
IT業界でも売上高を急速に伸ばしている企業は多数ありますが・・・
売上の10%前後が資金回収ができていない。

ようは売り上げの90%以下であり、急速な売り上げの伸びが逆に資金回収不足に陥っている。
今後、どのようになるかと言えば、2013年以降は、15~20%まで資金回収ができなくなる恐れも出てきているそうです。
勝ち組もこのような現状。

2013年以降の日本経済は、多難であるが、確実な商売が必要になってくることでしょう。

2012年特集-1

2012年の総選挙の結果は選挙前からの予想通り。
今回、自○党は選挙準備が終わり、程よい時期に選挙、まさに千載一遇のチャンスでした。
政権与党は、争点がないなまま、準備不足感が歪めないままの選挙・・・
また、第3極は準備不足はゆがめられない。
政治運動は得意の人は多くとも、政治家になれるのはほんの一握り。

期待しすぎて、こけてしまった政党。出直しをするにも相当の体力が必要。
根気よく出なおしてほしい。
今回政権をとったほうも喜べないのは確か・・・
いまは何重苦の日本。立て直すのも容易ではない。

誰がそうしたのかといえば、国民すべて責任。
誰が悪いとも言えないのが事実。

日本国、今後は見守るというより、自分にできることは、個人でやりましょう。
国に頼ってもいまは難しいでしょう・・・

Apache設定-2

Port 80

　ポート番号
　WWWサーバー（http）は通常80番を使用するので特に変更する必要はありません。ASSLを用いる場合は、HTTPSとして割り当てられている443番、社内などの限られた範囲で使用する場合には 8080番を用いるのが一般的です。もし。80番以外を使用する場合は、他のサービスで使用されている番号以外、特にウェルノウンポート以外の番号を用いるようにしてください。

ServerAdmin koro@mydomain.com
　エラーメッセージの送付先（サーバーの管理者）
　インストール時に記入したメールアドレスが表示されています。これは、致命的なエラーが発生した際にWebマスターとして登録されているE-Mailに送るようになっています。その送り先を指定しているのがServerAdminのディレクティブです。送り先を変更したい場合は各自で変更してください。

ServerName xx.cc.jp
　サーバー名
　インストール時に記入したホスト名、もしくはIPアドレス（127.0.0.1など）が表示されています。LAN内での動作確認を行った後は、本格的な公開前に必ず独自のドメイン名、あるいはDynamic DNSサービスで取得したサブドメイン名を入力しておくようにしてください。

DocumentRoot "C:/Program Files/Apache Group/Apache/htdocs"

　ドキュメントルート（公開ディレクトリ）
　Webコンテンツのルート（最上位）ディレクトリを指定します。デフォルトでは「C:/Program Files/Apache Group/Apache/htdocs」となっていますが、好きな場所に指定しても構いません。個人的には、デフォルトだと階層が奥深いこともあり、管理面で面倒くさい事も多いので違うドライブを指定しています（例：G:/Public_Html ) 。なお、ここで指定したディレクトリのみが公開の対象となり、これより上位のディレクトリへはアクセスできないようになります。


Options FollowSymLinks
AllowOverride None

　ルートディレクトリのアクセス権
　ルートディレクトリのアクセス権を設定します。ここでは、シンボリックリンクの使用を許可し、「.htaccess」を用いた固有のアクセス権は認めない指定になっていますが特に変更する必要はありません。なお、CGIを使用する際には「Options ExecCGI」のように「ExecCGI」を付け加えます。
■all Multiviews以外の全てのオプションを指定します。
■Indexes インデックスの一覧表示を許可します。
■Includes SSIの使用を許可します。
なお、「IncludesNoExec」とすることでExecコマンドとCGIのincludeは含まなくなります。



#
# This may also be "None", "All", or any combination of "Indexes",
# "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
Options Indexes FollowSymLinks MultiViews
#
# This controls which options the .htaccess files in directories can
# override. Can also be "All", or any combination of "Options", "FileInfo",
# "AuthConfig", and "Limit"
#
AllowOverride None
#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all

　ドキュメントディレクトリのアクセス権
　Options Indexes FollowSymLinks MultiViews
　・・・の範囲は、ドキュメントディレクトリへのアクセス権を設定しています。デフォルトでは、インデックスの一覧表示とシンボリックリンクを許可しています。ウィンドウズにはシンボリックリンクの機能がないので、コメントアウトしても構いません。
AllowOverride None
アクセス権を指定していません。
Order allow,deny
4行目の「Order allow,deny」では、アクセス「allow（許可）」と「deny（拒否）」の評価の順番を指定しています。この指定では、それ以下に「Allow」と「Deny」の両方が指定されていた場合、「Allow」の指定を先に処理し、「Deny」の指定を後から処理しています。指定に矛盾が生じた場合には後から処理したものが有効となります。
Alow from all
5行目の「Allow from All」では、アクセスの制限を指定しています。「Allow from All」だと、「アクセス制限を設けない」=「全てのアクセスを許可する」という設定になっています。仮に制限を設けたい場合は、IPアドレス、またはホスト名（FQDN）のいずれかで指定することになります。以下の例を参考にしてください。
◎アクセス制限の設定例
Allow from 192.168.0.150 ←「192.168.0.150」のIPアドレスだけ受け入れる。
Deny from 192.168.0.150 ←「192.168.0.150」のIPアドレスだけ拒否する。
Allow from 192.168.0 ←「192.168.0」を含む全てのホストを受け入れる。
Allow from jj.mydomain.com ←「jj.mydomain.com」のホストだけ受け入れる（小分類）。
Allow from mydomain.com ←「mydomain.com」のホストだけ受け入れる（大分類）。
■ExecCGI CGIの使用を許可します。
 
UserDir "C:/Program Files/Apache Group/Apache/users"

　ユーザーのホームディレクトリ
　ユーザー個別のディレクトリの作成を行うモジュールの「mod_userdir.c」の指定を行います。「IfModule」は「モジュールが組み込まれている場合は」という判断を行い、もし組み込まれている場合にはその指定をおこなうようになっています。デフォルトでは「C:/Program Files/Apache Group/Apache/users」となっています。


DirectoryIndex index.html

　ディレクトリインデックス（索引）表示
　ディレクトリインデックス表示の作成を行うモジュールが組み込まれているかどうかを判断し、もし組み込まれていた場合には、その指定を行います。ディレクトリインデックスとは、Webページを最初に表示するファイルのことで、通常は「index.html」となっています。
例：）

DirectoryIndex index.html index.htm welcom.html welcom.htm default.html default.htm


AccessFileName .htaccess

　個別ディレクトリのアクセス制御ファイル名
　公開するディレクトリ中で特定のディレクトリだけを公開したり、アクセスできないようにしたりすることができます。ここで指定したファイルに記述されている内容をアクセス権として設定します。アクセス制御ファイルとして、一般的には「.htaccess」というファイル名が使われます。



Order allow,deny
Deny from all
Satisfy All

　.htaccessドキュメントへのアクセス権

　上記で説明した「.htaccess」ファイルはアクセス制限を行うディレクトリの中へ格納します。しかし、アパッチのバージョンによってはWebブラウザなどで正確にパスを記述すると、その中身を閲覧することが可能となってしまいます。そこで、このディレクティブでは「.ht」で始まるファイル名には基本的にアクセスできないように指定しています。
Deny from all
「.htaccess」のファイルが格納されたディレクトリはアクセスを拒否するという設定です。
Satisfy All
ファイルへのアクセス条件を設定するためのディレクティブです。指定値は「Any」と「All」があります。「Any」にすると、アクセス時に要求されるユーザー名とパスワードの組み合わせだけが正しいか、またはアクセス許可されているホストからのアクセスであるかのどちらかの条件を満たせば、アクセスを許可します。「All」にした場合は、その両方を満たさない限りアクセスを許可しません。厳格にアクセス制限かける場合には「All」のままにしておいてください。

Apache設定ファイル-1

◆Global Environment
ServerType standalone
　サーバーの起動方法。他に「inetd」が設定可能だが、「standalone」になります。

ServerRoot "C:/Program Files/Apache Group/Apache"

　サーバーのルートディレクトリ
　Apacheインストール時に設定した内容が反映されています。重要なコンテンツを含んだセキュアなサイトを公開するような方は、ここでルートディレクトリを変更することができますが、通常はこのままで構いません。
　また、「httpd.conf」のパスの指定の際には「￥（エン）」ではなく「/（スラッシュ）」を使用

PidFile logs/httpd.pid

　プロセス番号記録ファイル
　Pid（Process IDentification number：プロセス番号）を記録するファイルの指定を行うディレクティブです。Windowsの方は特に変える必要なし。

ScoreBoardFile logs/apache_runtime_status

　内部情報ファイル
　Apacheの内部情報を記録するためのファイルを指定します。Apacheが動作する上で必要となるファイルなので、このディレクティブは変更しない。

Timeout 300
　タイムアウトまでの時間
　クライアント接続要求を受け取ってから、コンテンツを提供するまでの連続してパケットを送信する時間の最大値を指定します。単位は秒単位です。
　ここで設定した時間を過ぎてもパケットが送信されない場合、ブラウザはエラーメッセージを表示するようになります。クライアントの回線の速度にもよりますが、１ページあたりの送出データがよほど重くない限りは、３００秒あれば十分といえるでしょう。それを超える値も設定できますが、サーバーに余分な負荷がかかるので適度な値に設定するようにしてください。

 KeepAlive On
　キープアライブ
　クライアントからの要求があり、いったんコンテンツを提供した後もコネクションを閉じずに次の要求に対してすぐに応答できるようにする機能です。通常はアクセスがあった場合、リンク部分をたどって他のページを見にいこうとするので、このディレクティブが「On」になっているとパフォーマンスが向上します。

MaxKeepAliveRequests 100
　最大キープアライブ値
　各々の接続に対するキープアライブの最大数を指定するディレクティブです。この値を「0」にすると無制限になりますが、サーバーへの負荷も考えるとデフォルトの１００のままで良いでしょう。実際に、運用していって問題があるようなら値を変更してパフォーマンスとのバランスを取るようにしてください。

KeepAliveTimeout 15

　キープアライブタイムアウトまでの時間
　ひとつの要求が完了してから、コネクションを切断しないで次の要求を受け入れるまでの時間を指定するディレクティブです。単位は秒単位です。この値が短すぎてもサーバーへの負荷が増大し、反対に長すぎるとレスポンスが悪くなるので適度な値を指定するようにしてください。

#MaxRequestsPerChild 0
　子プロセスの処理可能数
　Apacheはクライアントから要求があるたびに子プロセスを作り、リクエストに応じます。このディレクティブでは子プロセスが終了するまでに処理可能な要求の数を指定します。この機能はUNIX系OSでのみ有効で、ウィンドウズでは無効とされるのでハッシュマーク(#)をつけてコメントアウトしても構いません。

ThreadsPerChild 50

　リクエストを処理する子スレッドの最大数
　Apacheが提供するWebページが同時に処理できるヒット数を指定するディレクティブです。これはウィンドウズ系Apache固有のものでUNIX系OS用のApacheにはついていません。デフォルトで問題ありません。

ClearModuleList

　組み込まれたモジュールリストのクリア
　Section2以降で述べる「AddModule」ディレクティブによって組み込まれた実行可能なモジュールのリストをクリアする指定です。Apacheの起動時は「httpd.conf」の行頭から順に処理をしていくので、ここでモジュールをクリアして、その後で、モジュールの組み込みを行うという段取りをとります。このままにしておいてください。

・・・
AddModule mod_so.c

AddModule mod_setenvif.c
　モジュールの組み込み
　Apacheは基本的な機能の他にモジュールを組み込むことによって、機能を拡張することができます。これらのディレクティブでは、引数として指定されたモジュールの組み込みを行います。

日本の景気動向

日本の景気動向は悪い。
内需は少なく、輸出は政治がらみで中国、韓国とうまくいかず、またアメリカについては景気の良しあしが不安。

今後は波乱含みの選挙。。。。政権交代が決まっているような感じである。
2013年以降は政治動向によって、大きく経済が閉塞する可能性があるので注意を要する

円高は続く・・・

日本経済は過渡期、そしてなぜか、欧米が危機になると、円が買われる
決して、日本経済がいいという意味で買われているのではない。
下記は矛盾もあるがこれが実情であろう

1. 日本の財政状態は危機的状況であるが、日本国債は日本国民の所有がおおいので、いざとなれば、日本国民の痛みを伴った処理で、日本国の財政は借金0が可能
2. 経済がガラパゴス進化をしており、欧米から見れば、安全性が高い
3. 中国の国際化が進むまでは、日本の円
4. 日本経済が国際化する可能性
   　海外に出てゆく企業が多いが円建てにしない
   　日本の金融が海外に出てゆく
   　日本国民が日本国を出ていく
5. 日本国内の慢性的ガラパゴス化

HTML5-4

コンテントモデルとカテゴリとの関係

【例】

①body要素
　カテゴリ：セクショニングルート
　コンテントモデル：フロー要素

②h1要素
　カテゴリ：フロー要素
　コンテントモデル：フレージング要素

③p要素
　カテゴリ：フロー要素
　コンテントモデル：フレージング要素

④テキスト
　カテゴリ：フロー要素、フレージング要素
　コンテントモデル：なし

⑤a要素
　カテゴリ：フロー要素(フレージング要素の場合あり)、インタラクティブ要素
　コンテントモデル：親要素を継承するが、インタラクテイブ要素を持てない

⑥div要素
　カテゴリ：フロー要素
　コンテントモデル：フロー要素

⑦img要素
　カテゴリ：フロー要素、フレージング要素、エンペッディド要素
　コンテントモデル：空要素

• body要素内にh1要素、p要素は可能
• p要素のフレージング要素なので、子にフロー要素を持つことができません。
• div要素内のa要素は、親要素を継承すると、フロー要素となり、a要素の子にp要素を含めることは可能
• p要素内のa要素は、親要素を継承すると、フレージング要素となり、a要素の子にフロー要素を持つことはできません。
• img要素はフロー要素、フレージング要素、エンベッティング要素ですので、子になることは可能。
• 同じようにテキストも子になることが可能
• 上記は透過性という

HTML5-3

カテゴリについて

①メタデータ要素
　head要素内ににかける要素
　title、link要素など

②フロー要素
　body要素内に含めることができる要素、ほとんどの要素がこれに含まれる

③セクション要素
　Webページのセクションを構成する要素
　article、aside、nav、section

④ヘディング要素
　見出しを構成
　h1～h6、hgroup

⑤フレージング要素
　要素の内容がテキストや画像などのコンテンツそのものという要素
　a、audio、img・・・

⑥エンベッディド要素
　HTMLドキュメントの外部のリソースを参照する要素
　フレージング要素が含まれる

⑦インタラティブ要素
　ユーザ操作に反応するタイプの要素
　a、select要素など

次回はコンテントモデルとカテゴリとの関係です

HTML5-2

HTML4とHTML5との特徴的な違い

①HTML4では、HTML書式とXHTMLの書式が複雑であったが、HTML5では統一された

②DOCTYPE宣言が1種類で大文字・小文字区の区別がなくなる

③コンテントモデル(タグの役割の変更)
　Webブラウザにわかりやすくするのが目的・・・視点を変えれば開発者が利用しやすい
　HTML4でわかりにくかったブロック要素とインライン要素を明確にしている

　コンテントモデル：ある要素がもちうるようその内容を示す(P要素ならP要素)

　カテゴリ：似たような性質をもった要素をグループ化させる
　　カテゴリの関連性については下記のURLを参照
　　http://www.w3.org/TR/html5/

カテゴリについては次回

HTML5-1

HTML5についての基本的特徴と古いWebブラウザを利用する場合について

①HTML5はHTML4と互換性がある

②IE6～8はHTML5に対応していない。
　対応させるにはJavaScriptのライブラリを利用する(完全対応ではない)
　http://code.google.com/p/html5shiv/
　より、ZIP形式のライブラリをダウンロードする。
　HTMLファイルのヘッダ部に下記の文を追加
　(jsファイルをdistの下に配置を前提とする)
　
　
　上記についてはタグのみで属性は認識させることができず、CSS3の機能の多くは利用できない。

人との接し方-2

人と接する場合、

1. 自分の育った環境などの常識は持ち込まない
2. 「常識」や「当たり前」などの表現を用いない
3. 相手の表現や文章の間違いを指摘しない
4. いい間違えたと思ったら、表現方法を変えて、聞き返す
5. 相手に対して注意をしない
6. 知識を持っているからといって偉いのではない
7. 学歴や会社などの自慢をしない
8. 聞かれていないことについて話をしない
9. 話をしたくないときは、「話をしたくない」と主張する
10. 遠慮や遠回しの表現を用いない

なぜならば、育った環境でさまざま、
自分の中で正しさや、社会一般の正しさを常識や当たり前と考えないことが必要。

年をとると、上位者の感覚で若者に接するが、これは違う。
アドバイスを求められたときの診話をすべきである。
常に上目線から言われるていれば、命令であって、コミュニケーションではないことを自覚しましょう。

人との接し方-1

人との接し方が下手な人は多い。
また、何を話をすればいいのかわからない人も多い。
表現方法、国語力不足・・・と様々である。

誰もが人とのコミニュケーションをうまくできる人、またマナーに優れた人はいない。
どこかしらかにうまくできないことが多いです。

失敗をけなす人、注意をする人など、相手のことを考えずにいう人が多い。
評論家的行動をとる人が、追い込んでしまい、今の社会、うつなどになりやすい。

相手が何をいいたかったのかをまず聞きましょう。
表現法が悪い時もあるし、時間がかかることことも多い。

ゆっくりと話をしましょう

サーバサイドJavaScript-2

◆Nodeのインストール

http://nodejs.org/のサイトで，WindowsとMacにはインストーラが，そしてLinux用にソースコードが提供されている。
インストーラは実行すると，Windowsは「C:\Program Files (x86)\nodejs\node.exe」と，Macは「/usr/local/bin/node」として，それぞれ実行ファイルがインストールされる。

基本的にLinuxにおいては，ソースコードからのコンパイルになります。GCCなどのコンパイラ環境がすでにインストールされている状態で，次のような手順でインストール

$ wget http://nodejs.org/dist/v0.9.2/node-v0.9-2.tar.gz
$ tar zxvf node-v0.9.2.tar.gz
$ cd node-v0.9.2
$ ./configure
$ make
# make install

最後の「make install」はrootユーザで行い，「/usr/local/bin/node」として実行ファイルがインストールされます。


◆モジュールの使い方について
ブラウザ上で動くJavaScriptはすべてのjsファイルがマージされたものとしてスコープが適用されますが，nodeにはモジュールという単位で各機能を分割することができます。

モジュールが1つのjsファイルとなります。それぞれのグローバルスコープはそれぞれのjsファイル内で"閉じた"状態になり，exportsオブジェクトを通して外部に渡すことができます。モジュールの参照はrequire関数を使います。読み込んだモジュールのexportsオブジェクトを返してくれます。

モジュール参照の一例を見てみましょう。
exports.printFoo = function(){ return "foo" }

このコードをfoo.jsファイルとして保存します。このfooモジュールは，文字列「foo」を返すだけのprintFooメソッドを実装しています。

var foo = require('./foo.js');
console.log(foo. printFoo());

こちらのコードをmain.jsファイルとして，同じディレクトリに保存します。foo.jsをモジュールとして読み込んで，fooオブジェクトで参照します。printFooメソッドの結果をコンソールに出力します。

node main.js

を実行すると，コンソールに「foo」と出るのが確認できます。

*ファイルはUTF-8で保存することによって、日本語が取り扱える。

サーバサイドJavaScript-1

◆Node.jsについて

Node.jsとは，ブラウザGoogle Chrome用に開発されたJavaScriptエンジンV8がサーバ上でプログラムを実行できるように，ファイルやネットワークI/Oなど多くの機能を追加したもの。

軽量で効率よく多くのリクエストを処理するネットワークアプリケーションの構築ができるプラットフォーム

①2つのモデル
・ノンブロッキングI/O
・イベントループ

JavaScriptの1つの特徴にシングルスレッドで動作している。
これはNode.jsでも同様で，デッドロックなどを意識する必要がないが、一度に1つの処理しかできないため複数の処理ができない。
そのためNode.jsではノンブロッキングI/Oを採用
従来型たとえば，データベースにアクセスして検索を実行して結果を取得する。この場合，データベースに問い合わせてから結果が返ってくるまで，待ち時間となる。
一般的にはライブラリなどでデータベースから結果が返るまでの間，呼び出し元の処理をとめている。そのため結果を利用した処理を続けてできます。
ノンブロッキングI/Oは，データベースに問い合わせたら次の処理に移ります。結果の受け取りはコールバックで実現。このように基本的に重い入出力処理は非同期で実行するのがノンブロッキングI/O

イベントループ
さらにリクエストやコールバックの発生はイベントとして扱い（登録し），そのイベントに関する処理が終わったら，次のイベントを処理する。このようなイベントループをNode.jsは採用している。

うれしい悲鳴

先週の木曜日から、今週の月曜日までに、オファアが4件、すべて見積もり即決で、すべてから発注依頼となりましたが、戦力としては１件のみの受諾に。

全部は受けられないし、いろいろな技術課題もあるので、１件の選択、
時期を変えて依頼を受ければいいのですが、どれも期間が長め・・・

うれしい悲鳴です。

node.jsを使用しているシステムが増えている、まだまだ課題が多い技術。
今後盛んになるのかは、まだまだ未知数。

しかし、エンジニアは流行に関係なく、技術および背後にある技術仕様を取得してほしい。

Webエンジニア像

2週間にわたり、業界トップWeb系会社数社と話をすることができました。

エンジニア像や各業界の今後におけることなど様々なことを、短い時間でお話をすることができて光栄。
本来、御話をする機会がないとはずでしたが、偶然、お話をする機会をいただいたので、まとめてみました。
詳細についてメールでお問い合わせください。

Web系の想定されている問題点


・アジャル開発の限界の問題

・高負荷の問題

・クラウド環境でのアプリ開発の問題

・新技術への対応問題

・スマホなどに対する問題   某企業が持つ子会社がもつ、球団のマスコット？

IT業界の勢力が変わる

先週より、渋谷系の企業との打ち合わせが増える。
売上高では、大手には負けるものの、Web企業が伸びている。
個々の企業がなければ、通信キャリア会社にとっては打撃になる企業レベル。

経営者や技術者の方とお話をすると共通点は
①既存のやり方を履修せず、挑戦し続けること
②アジャル的思考
③結果を恐れず、目的に向かう
④時間厳守

大手SIでは、上の④についてルーズである。
逆に渋谷系企業軍は、時間厳守に結果を求める思考が強い。

売上高を見ても、1年前が数百万円で、今年は数億や10億円以上になるという、
Web系バブルと言われている
・・・これはWeb企業の経営者が言っている事実。

今後、タブレット端末でネットワークビジネスが更なる進化があります。
この点を見あやまなければ、さらに、大きな企業が出てきます。

企業が大きくなれば、組織編成が変わり、安定収益になりつつあります。
おもしろく、技術者も伸びる理由がわかります。

先日、Windows8が発売され、更なる進化と技術が求められそうです。

ソフト業界は今

ソフト業界の過渡期なのか、いろいろなプロジェクトが失敗している。
失敗といっても納期遵守を守ろうとして、無理に無理を重ねている。
要因はなにか？
客観的には簡単であるが、当事者になると、忘れること
・当たり前のこと当たり前にやれない
・時間厳守の行動
　たとえば、19時ごろに会議をして方針を決め、21時ごろに一斉にやり出す
　これは体力消耗戦で全く機能しない。そしてこの繰り返し
・勝手に判断し、勝手に作り出す
　後から、修正が増える
・リーダーらしきものが何人もいてかじ取りが失敗する。

これらは観ているとよくわかることであるが、いざ当事者になると、不思議と上の様な事を行う。
業界の不思議さ？

ある程度ルールを作って、行う必要性を感じるが、それを実践する人が少ない。
これが最大の要因。

サーバサイドJava-002

第2章
必要なソフトウエアをインストールおよび設定する

①JDK7のインストール
②TOMCAT7.0のインストール
③MySQL5.5のインストール
④Eclipseのインストール

各種設定は設定ファイルを参照

サーバサイドJava-001

第1章の基本的まとめ

1-1
【Webアプリケーションとは】
インターネット機能を特徴を利用したアプリケーション

①Webアプリケーションを公開するにはWebアプリケーションを実行するための環境Webサーバが必要
②利用する際はネットワークに接続したパソコン、携帯端末のWebブラウザが必要

具体的なものは
①インターネット検索エンジン(Google、Yahooなど・・・)
②アマゾンの通信販売
③Twitter、FacebookなどのSNS(ソーシャル・ネットワーキング・サービス)
など

【サーバとクライアント】
サービスを提供するのがサーバ
サーバが提供するサービスを受け取るのがクライアント

【静的なページと動的なページ】
静的なページ：ブラウザなどのクライアントやサーバの状態によらず、常に同じコンテンツを返す
動的なページ：ブラウザのリクエストの内容やサーバの状態によって返すページを毎回生成して返す

検索エンジンによって検索すると、毎回違うページになっていることが見られます。

1-2
【Webアプリケーションに必要なもの】
①WebアプリケーションはHTTPと呼ばれるプロトコルを利用して、サーバとクライアントとの通信を行う。
②Webクライアントはブラウザ
③Webアプリケーションの動かすにはアプリケーションサーバが必要
　(Webサーバとアプリケーションサーバが一緒なものもある)
　＊Webサーバとは本来、HTTPサーバという

Webのプログラム
①URIを指定して実行
②プログラムは利用するユーザの情報をデータベースから参照/格納し、メールサーバと通信を行い、登録されたメールへ登録完了のメールを送信するなど行ったサービスを提供します(ショッピングなど)

【サーバサイド技術】
サーブレット
①オブジェクト指向言語
②マルチプラットフォーム

JSP

2012年度下半期のビジネス展望

2012年度下半期の日本のビジネス展望は厳しいのが実情。
①日中関係
②日韓関係
③日米関係

上記の国の関係がぎくしゃくしている。
今後貿易に影響し、すでに影響しているものも多数。
国内産業に大きく影響が出てくるでしょう。

特に日中関係、現在の日本の貿易相手国の主流。
産業にどれだけ影響を及ぼすかは未知数、
というより、影響が大きすぎてこれからが心配。

外交は難しいのが常、
単なる常識や国際法に基づかないのは周知事項というべきでしょう。
隣国なのに、コミュニケーションは遠い国にならないようになってほしい。

毎週金曜日はビジネス展望の記事になります。

日本技術レベル展望

以前までは日本の技術力は素晴らしいものだと思っていたが、
実は単なる応用のみで、基礎的な力がないことが分かった。

単なる応用では素晴らしいが、ほかの国が同じことをすれば、人件費が高い日本では競争力がない。
これでは技術力ではなく、技能力？
今後、日本が技術力で勝つには、分野ごとではなく、総合的に集団化することが必要。

提案としては
①東北の復興を考え、技術、研究分野を集めた集合的企業団地の創設
　1-1　大学の研究と企業研究の提携
　1-2　産業の育成
　　1-2-1　20代の企業家を育成
②産業はロボット化をしない。
　2-1　産業団地として住分野の無料化
　2-2　老若男女問わず、働ける場所を作る
③日本産業の再構成
　3-1　単純作業の効率化をしない
　3-2　技能の育成

詳細については今後記事にしていきます。

スマホ

スマホのアプリは以前から企画～製造していましたが、スマホ自体は持っていなかった。
でも購入して、いろいろな分野に進出ができそう。

手入力や、ジェスチャ機能は今後スマホ、タブレット端末にとって良い操作性。

といって現在も入力系についてはまだまだ研究しているものが多く、さらに便利になれば、利用者が拡大します。

現在スマホは、電話＋小型のパソコン。
そのため、利用者の中には、まだまだ操作に慣れていません、今後この部分をどうするかが悩みになりそう。

大学院での講義

先日、とある大学院で情報処理全般についてゼミに参加し、講義、2時間ほどでしたが、大学院生と有意義に会話ができたので、わたしのとても楽しい講義になりました。

学生の多くは教授になっていく人が多い。

教えるという意味ではなく、今後の課題や、またどのように思考すべきかとい話題が中心。ほとんどがQ＆A形式。

足の怪我もあり、お断りも考えました、貴重な経験を積観ますよという一言に負けて講義。
20代の人に頑張ってもらって、情報系の将来を変えてほしいの熱望します。

今年は京大・・・

メールを読むと
NICT、電子情報通信学会 ネットワーク仮想化時限研究専門委員会

他共催の「第2回ネットワーク仮想化シンポジウム」が8月24日(金)に
京都大学で開催されます。また、関連するワークショップも前日に開催されます。

・・・今年は京都ですか。 足の怪我もあるからいけない。 ネットワークの仮想化は昨年から興味津々でしたが、あきらめました。   猫のように寝ていよう(^▽^;)

 

                               

技術力・・・

先日、ＴＭからの依頼の金型設計、技術力のある会社に依頼すると、完成。
紹介しただけに気になりましたが、うまくいきよかった。
あるパーツについてはどこでもできない。

怪我をしていただけに最終段階のところで人任せになってしまった。
完成してほっとする。

これからは、人に任せることは任せて、管理だけにします。

後は、海外生産になるが、一部は国内生産。
まだまだ日本国内で生産しなくてはいけないものは多数。
これからの技術力に期待します。

暑中お見舞い申し上げます。

暑い日が続きます。
熱中症にならないように気をつけましょう。

最低気温が下がらないのがつらいですね。
単なる水分ではなく、薄めの塩分のあるもの物をとりましょう、

でないと、水分をとっていても熱中症になりますので気をつけましょう。

現在検討中。

現在、仕事が超多忙。
機密事項ばかりで暮らしています。
暇といえば暇なような、忙しいといえば忙しい・・・
何のことかといえる(爆笑)

かかとを怪我をして、少しお疲れモード。
それにかかとが痛い。
集中力に欠けるし、痛みで・・・

といいつつ、順調に回復中。
また、何かの流れが変化、万事塞翁が馬～

怪我

階段を踏み外して、かかとを強打。
当分、何も書けなくなります。

ブログのほうは、お休みします。

Cosminexus 覚書

Cosminexusの資料
http://www.hitachi.co.jp/Prod/comp/soft1/manual/common/cosmi/v9/index.html#cosmi01

DTOについて

◆DTOとは
Data Transfer Object（DTO）はデザインパターンの一種で、アプリケーションソフトウェアのサブシステム間でデータを転送するのに使う。


Data Transfer Object とビジネスオブジェクトや Data Access Object との違いは、DTO が自身のデータの格納と取り出し機能（アクセサメソッドとミューテータメソッド）しか持たない点である。

円高が過熱？

ギリシャの動向によってECがどうなるのか不安。
ギリシャがユーロから離脱すれば、ヨーロッパの経済はさらに不安定なものになりるのは確実。銀行などの信用問題が発生しそう。

これにより、さらなる円高の可能性が高い。
日本がそのため、ヨーロッパに対して支援しているのは、ヨーロッパ経済が混乱しないようにするための策。

不安要因があると、経済が止まり、心理不安がさらに加速するのではないかと新派しています。

今後のヨーロッパ状況はしっかり押さえましょう。

IT教育について

IT教育については、どこでも難しさが出ているようです。
①1個の技術だけでは対応できない
②複雑性
③技術進歩
④APサーバの影響
などなど、各種の問題が混在化しています。
どうしてでも、開発段階で「えいやー」というのが開発現場で聴かれる言葉・・・

今後もこの状況が続きます。
IT教育で必要なのは、現状に対応するのではなく、理屈を知り、そこから応用が効く技術者を育成することが主です。
そのためか、どこの学校でも資格試験対策になってしまうのが本音。

今週はいろいろなイベントでしたが、来週からは仕事に集中。
いろいろ楽しい日々だった今週、来週はつらくなりそう(大汗)

東京スカイツリーの展望室

21日、東京スカイツリーに登る。
エレベータが止まるハプニングもありましたが、19時30分より21時まで360mの展望室に滞在し、夜景を楽しみました

350m展望室に登り夜景を見るまでの動画です。

金環食

21日、曇り空ながら、金環食を見る。
日本中、太陽を見ていたでしょう。

はじめてみましたが、感謝感動です。
雲がいいフィルタとなり、撮影によし、肉眼で見ても大丈夫でした。

ストレージ技術 覚書3

◆サーバー仮想化とストレージ仮想化

■サーバ仮想化
　サーバー仮想化では、1台の物理サーバー上に複数の仮想サーバーを動作させます。そのため、物理サーバーを統合し、使用率を向上させ電力やサーバー・スペースにかかる費用の削減なども可能です。仮想サーバーは、物理サーバーに比べ、圧倒的に迅速にユーザーに提供できるだけでなく、逆にサーバー・リソースが不要となった場合でも、容易に「廃棄」することが可能で、プロジェクトの効率化を実現します。

　さらに、サーバー仮想化環境では、物理サーバーの負荷変動や要件に応じて、指定したタイミングで仮想サーバーを物理サーバー上で移動させることが可能です。これは、物理環境で常につきまとってきた互換性に要する複雑さを軽減させる第一歩と言えます。

　ストレージ仮想化と別々にとらえられがちなサーバー仮想化技術ですが、サーバー仮想化においては、SAN（Storage Area Network）すなわちストレージ階層において、集約された高速大容量のI／Oのリード／ライトや複数サーバーのイメージの移動が発生します。そのため、パフォーマンスや容量増加の適切な対応、可用性向上、さらに効率的かつ最適化されたパス管理などを実現するストレージ仮想化がサーバー仮想化を支える重要な技術となります。

■ストレージ仮想化
　ストレージ仮想化によって、サーバーに影響を与えない、複数のディスク階層間、異機種混在環境を含む、ストレージ筐体（きょうたい）間での無停止のデータ移行が実現されます。後ほど詳しく触れますが、「今すぐ活用できるストレージ仮想化技術」としても仮想プロビジョニングや仮想LUNなどの先進のストレージ仮想化テクノロジーがEMCのSymmetrixやCLARiXだけでなく、各社の高性能なSANストレージ製品で提供されています。ストレージ仮想化の本質とは、複数のストレージ階層を単一の管理基盤の下で統合するものです。これによって、すべてのストレージ階層を容易かつ迅速に構成、管理し、環境を劇的に単純化し管理にかかるすべての手間とコストを削減します。

◆ストレージを効率良く運用する仮想プロビジョニング
（1）仮想プロビジョニング
　仮想プロビジョニングでは、サーバー、アプリケーションに対して、実装している以上の容量を仮想的に割り当て、プール化された共通プールが実際に使用している分だけが物理的な割り当てとなるため、利用率を大幅に向上できます。


　通常、新規のアプリケーション用などにストレージをプロビジョニングする場合、管理者は現時点で必要な容量ではなく、将来必要となる容量を考慮してプロビジョニングを行います。その際、ストレージ容量がなくなり、アプリケーションやビジネスのプロセスが停止してしまうリスクを軽減するため、また近い将来、再度プロビジョニングしなければならない頻度を減らすために、管理者ははじめから実際に必要以上の物理ストレージを割り当てしまいがちです。それにより、調達や運用の費用の悪化をもたします。

　これらの問題を解決するのが仮想プロビジョニングです。これは「シン・プロビジョニング」ともよばれ、必要な場合にのみ共通プールから物理ストレージを使用して、ホストに自動的に割り当てます。仮想プロビジョニングによって、ストレージの有効活用だけでなく、従来のストレージ・プロビジョニングにかかっていた手間や時間を劇的に削減することが可能です。

（2）仮想LUN
無停止でデータを移行する仮想LUN


　仮想LUN（Logical Unit Number）は、単一のストレージ・システム内において、移行元となるLUNから同じ、もしくはより大きいサイズの移行先LUNに対して、アプリケーションの停止を伴わないデータ移行を実現するテクノロジーです。仮想LUNは下記の価値をユーザーにもたらします。
・ストレージ筐体内での情報ライフサイクル管理（ILM）の実現
・パフォーマンスの向上
・無停止のシステム構成変更

　仮想LUNにより、効果的な情報ライフサイクル管理戦略の構築と実行が可能です。情報ライフサイクル管理とは、あらかじめ定義したポリシーに従ってアクセス頻度の少なくなったデータを、高速なファイバ・チャネル・ドライブからより低速で大容量、安価なSATAドライブなどに自動移動させる技術です。これにより、ハードウエア・リソースをより効率的に使用し投資対効果の最大化を図ることが可能です。

　さらに、仮想LUNは過負荷のディスクから負荷の低いディスクにデータを移行させることで、パフォーマンス向上を実現します。従来、多くの通常の移行技術では、LUNの特性の変更は許されません。一方、仮想LUNは、異なる特性のLUNへ移行することが可能で、パフォーマンス向上を実現します。また、仮想LUNによって、ディスク・アレイ・エンクロージャー間を無停止でデータ移動させることが可能です。そのため、ホストにかかるオーバー・ヘッドを削減し、システムを停止しないサービス・レベルを維持した構成変更を実現します。

（3）完全に自動化されたストレージ階層化　FAST（Fully Automated Storage Tiering）
FASTによる完全に自動化されたストレージ階層化

　仮想LUN機能をベースにEMC独自のテクノロジーとして提供しているのが、FAST（ファスト：Fully Automated Storage Tiering）です。FASTではストレージ・インフラストラクチャの管理を劇的に容易にし、ストレージにかかる全体的なコストが大幅に削減されます。

　またFASTは、変化するパフォーマンス要件に応じてストレージ階層間の動的なデータ配置や移行を自動化することで、適切なデータを適切なストレージ階層に適切なタイミングでの配置が可能です。コストとパフォーマンスに関する要件を最適化して、ストレージ階層化によるメリットを最大化します。

　特にEMCのハイエンド仮想ストレージSymmetrix V-Maxにおいては、価格性能比の観点から分類される、ストレージ階層に関するすべての選択肢を同一筐体で提供します。一例としては、以下の内容になります。

・「階層0」ストレージとして
最小限の遅延と高いパフォーマンスが求められるトランザクションへの対応としてフラッシュ・ドライブ。
・「階層1」として
パフォーマンス重視のアプリケーションへの対応として、15,000回転のファイバ・チャネル・ドライブ。
・「階層2」として
大量のデータの一括処理やバックアップなど比較的低いパフォーマンスでも十分で、コスト要件を重視する大容量SATAドライブなど。

　FASTでは、システムにかかる負荷は能動的に監視されます。これは使用頻度の高いデータはより高パフォーマンスのフラッシュ・ドライブへ自動的に移動され、逆に使用頻度の低いデータは、より大容量のSATAドライブに自動的に移動するという具合です。FASTはこれらの処理を動的かつサーバーを停止させず、ビジネス継続性や可用性に影響を与えずに実行します。

　また今日、フラッシュ・ドライブは、ストレージ業界に大きな変革をもたらしていますが、FASTによって、より多くのユーザーがフラッシュ・ドライブのメリットを享受できるため、導入の加速が期待されます。

（4）仮想環境でのパス制御
（5）物理と仮想環境のエンド・ツー・エンド管理
仮想環境でのパス制御、物理と仮想環境のエンド・ツー・エンド管理

　従来の仮想サーバー環境における複雑で限定的なフェイル・オーバーとロード・バランシング・ソリューションに対して大きな優位性を提供するのがEMC PowerPath/VEテクノロジーです。例えば、従来のパス制御に関するソリューションは、VMware VMotionなどの仮想マシン（VM）の移動に伴う、ストレージ・インターフェースの飽和による予期しないパフォーマンス劣化を避けることができませんでした。これに対し、高度なロード・バランシングとフェイル・オーバー機能を持つPowerPath/VEでは、仮想環境において常に高いパフォーマンス・レベルを維持します。PowerPath/VEはVMwareおよびHyper-Vの両方をサポートします。

　物理と仮想環境を包含するエンド・ツー・エンドのリソース・マッピングと管理は、仮想化を支える重要な技術です。EMCでは、物理と仮想環境における統合管理を実現するためのストレージ管理ソリューションを提供しています。そのためVMware vCenterと連携し、仮想マシンを特定し、適切なストレージ・リソースを割り当てるなどが可能です。

　今後、ますます現実化される仮想データセンターの進展においては、高度に統合されたサーバーやアプリケーションが、ペタ・バイト級の大容量ストレージを高パフォーマンス、高可用性のもとでアクセスする環境の構築、効率的な運用が必要です。

　そしてそれを支えるストレージ仮想化は、サーバー仮想化と両輪をなす重要なテクノロジーなのです。

ストレージ技術 覚書2

◆アクセス頻度によってストレージを使い分ける「ILM」

　ストレージ仮想化を使った応用的な機能として、ILM（Information Lifecycle Management）がある。ILMは、情報（データ）が生成され、利用され、最終的に破棄されるまでのライフサイクルを、主にアクセス頻度に注目して数段階に分類し、それぞれの段階で適切なストレージ・デバイスを使い分けようという発想だ。

　通常、生成されて間もない「新鮮な」情報は参照／更新ともに高頻度で行われる。この段階の情報は、アクセスが高速なストレージ・デバイスに格納しておかないと業務効率を低下させる要因にもなる。このため、通常は手持ちのストレージ・デバイスの中でも最も新しく最も高速なシステムがこうした用途に充てられる。

　例えば決算期にのみ参照されるデータであれば、保存用のアーカイブ・ストレージに移動しておき、決算期にはそこから取り出してくる、という運用でも効率面での悪影響は軽微にとどまるだろう。むしろ、オンライン・ストレージからめったに参照されないデータを排除することができれば、そのメリットがデメリットをはるかに上回ることが期待できる。

　こうしたデータの移動は、残念ながら人力で実施することが極めて困難だ。日ごと／週ごと／月ごとといった形で定期的に生成されるファイルであれば、ちょっとしたスクリプトを書く程度の手間で半自動化も可能かもしれない。しかし、通常はファイルに対してどの程度の頻度でアクセスが発生しているかの情報を把握することすら困難であり、データを移動してしまうとアプリケーションからデータを見つけることができなくなるなど、さまざまな弊害が出てくる。そのため、ILMはコンセプトとしては分かりやすいものの、実装は簡単ではないソリューションとなっている。

　現実のILMソリューションでは、仮想化技術と組み合わせることで実装上の困難を解消している例が大半だ。

　これには、仮想ボリュームと物理デバイスのマッピングをアプリケーションからは隠ぺいされた形で動的に変更できるという仮想化の特長が生かされている。データをその鮮度とアクセス頻度に応じた物理デバイスに移動しつつ、アプリケーションから見た場合のパスは不変に保つ、といった実装が可能なのは、仮想化技術ならではと言ってよいだろう。

ストレージ技術 覚書1

仮想化技術全般に共通する目標は、物理的なデバイスの詳細を隠ぺいし、制約を回避するために論理的なインターフェースを構築／提供すること、である。


ストレージの場合、基本となる物理的なデバイスとは、個々のHDDのドライブ単体ということになるだろう。

企業の情報システムでは、HDDの単体容量という制約を回避する技術は必須となる。

◆RAIDによるHDDの統合
　HDDの場合、「分割」と「統合」という2つの方向の「仮想化」がどちらも長く利用されてきている。

　まず分割は、パーティション分割としておなじみの手法だ。HDDの容量を分割し、それぞれを独立したHDDのように見せかけることができる。

　一方、統合に関しては、主にRAID（Redundant Arrays of Inexpensive Disks）が用いられてきた。RAIDとは、安価で低信頼のHDDを複数組み合わせて信頼性を確保しようとする技術だが、結果的にHDDの単体容量を超える記憶領域をつくり出し、物理デバイスの制約を超えた運用を可能にする。

　例えば、1TBのHDDを3台用意し、Dドライブ、Eドライブ、Fドライブとして接続したとする。この場合、ユーザーが利用可能な記憶容量は合計で3TBとなるが、この使い勝手は3TBのサイズのドライブが1台接続されている場合と同じにはならない。

どのデータをどのドライブに記憶したか、という情報をユーザーが正確に把握しておく必要があるという問題もあるが、

最大の問題は、1TBを超えるサイズのファイルを記録することができない、という点にある。

仮に、サイズが2.5TBの巨大ファイルがあったとしたら、このファイルを保存するためには最低でも3つの断片に分割して各ドライブに分散して記録し、使用する際にはこの断片をつなぎ合わせるという作業をユーザーが行うことになる。

一方、RAID-0によるストライピングを使う場合、ユーザーは3TBのドライブをDドライブとして使用することが可能になる。ここにはもちろん、2.5TBのサイズのファイルをそのまま記録することができる。物理的な実体としては1TBのドライブが3台あることに変わりはないが、これを統合して仮想的な3TBのドライブを創り出す

◆RAIDの限界
　RAIDで複数のHDDを統合する場合、当然ながら統合対象となるHDDはすべてRAIDコントローラーの配下に接続されている。ユーザーの目から見える具体的なシステム・イメージとしては、外部ストレージの筐体（きょうたい）内に収納されたHDD群が1つのRAIDシステムを構成している、と見える。

　逆に言えば、ストレージが複数台あれば、その数だけのRAIDシステムがあることになり、利用率の不均衡などの無駄が生じる可能性が高い。

　仮想化されたストレージでは、仮想化システムが配下のRAIDシステムの容量を束ねて仮想的なボリュームを創り出し、これに対するインターフェースをサーバー側に提供する。これにより、ストレージ筐体（＝RAIDシステム）の境界を越えてボリューム容量を拡張できる。

　現在のエンタープライズ・ストレージでは筐体当たりの最大容量はPBレベルまで達しており、この容量では記録不可能な巨大サイズのファイルを扱うことがあるとは思えないので、筐体をまたがったボリュームの統合は、サイズ的な制約を理由としているわけではない。ここではむしろ、論理的な統合によって運用の効率化や簡素化が実現できることが主たるメリットとなる。

◆仮想化によって得られるメリット
　ストレージ仮想化では、ストレージ・システムの筐体の境界をまたいだ容量の統合が可能になるため、容量を余らせているストレージ・システムの容量を別のストレージ・システムの容量とつなぎ合わせて活用する、といったことが可能になる。システム全体にわたる大規模なボリュームの整理統合を行うことなく、空き容量を活用することができるようになるため、ストレージ・システムを新たに追加購入しなくても当面の容量不足に対応可能となるわけだ。これは、IT投資の抑制にもつながるし、既存のITシステムの利用率を向上させることで投資効果を高めることにもなる。

　また、ストレージ・システムの境界をまたいだ統合は、物理的なデバイスの詳細をサーバー側から隠ぺいすることと同義でもある。サーバー側では、仮想化システムが提供する仮想ボリュームに対してアクセスしており、仮想ボリュームが実際にどの物理デバイスにマッピングされているかについては全く知らされない。

cosminxus

cosminxusでWebサーバを構築をするには、Javaだけの勉強では開発は不可能。
SOAの基礎知識などが必要。
サービス単位でアプリケーションを構築する必要がある。

最近、単なるJavaの教育では、SOAを構築するのは不可能。
今後、技術者の育成が必要。

人材育成

ビジネスで重要なことは新人の育成や中堅社員の教育です。
常識を知っていると考えて社員教育を怠っていると、社員は会社の期待に反して行動します。

時代、そして会社の方向性に沿って社員を育成しましょう。
社員を育成するときに重要なのは、育てる人が当たり前のことでも育てられる人に対して疑問がわくように教えることが必要。

単に怒ったり、感情的な言葉を言うべきではありません。
誰でも教えられるときは、何も知らないし、疑問が若いのは当然と思うことが必要です

愛情をもって接しましょう。

何か人材育成にお困りならばお問い合わせください。

IT教育レジュメの販売開始

IT教育用のレジュメのPDFダウンロードの販売を開始しました。
最初はJavaの基本

1. プログラム基礎
2. Java基礎文法
3. 変数
4. 演算子
5. 制御文

2回目以降の予定
Java基礎2　オブジェクト指向
Java基礎3　ファイル処理などのAPIの利用
データベース基礎　データベースおよびSQL
Webプログラミング基礎　Webプログラミング基礎およびHTML
Java応用1　サーブレットとJSP
Java応用2　サーブレットとJSPとデータベースの接続

Java演習講座1　顧客管理の作成
Java演習講座2　商品管理の作成
Java演習講座3　ショッピングサイトの作成

Java上級講座1　Struts
Java上級講座2　Spring

日本ビジネスの覚書

日本経済の問題点の覚書
①円高
　ギリシャ問題でさらにヨーロッパが不安定⇒円高
②税収の落ち込み
③日本経済の疲弊
　震災復興の遅れが心配
④建設インフラの劣化
　昭和40年代に建設された道路、下水道、橋の劣化
⑤財政赤字
⑥国外脱出組の増加
⑦少子化と老齢化

教育 その1

Webアプリケーションの教育指針
①Webシステムの説明
　ブラウザとWebサーバについて
　HTTPおよびHTTPSの通信制御について
　Webプログラミング説明
②Webプログラミングの目的
　最終的にはHTMLの作成
③データベースとの接続
　Namingサービスの利用
④プログラミングについて
　プログラミングのデータとリテラル
　データ構造
　アルゴリズム
　変数
　制御文
⑤各プログラミング言語仕様

気候不順

急に寒気団が南下し、天気が大荒れ。
雹に、竜巻・・・自然が怖い。

これからは情報を得ながら行動しなくては。

天気が悪いと、風邪おひく人が増えています。
健康に留意しましょう。

そろそろ

そろそろ忙しさから解放されそう。
ダウンロード型製品の製造に入ります。
まずは教育系のレジュメや演習問題の作成。
どのような形になっていくのか楽しみです。

円高は止まらない

円高は今後も止まらない理由は
①日本が不景気になっても財政赤字になってもアメリカ国債の売却はできない
　⇒ドルから円に換えるので円高の要因
②輸出産業の主体の日本企業はドル建て
　⇒ドルから円に換えるので円高の要因
上記①については、今後日本政府がアメリカ国債をどのように扱うかによって円高ではなく、財政赤字が増える要因になる

円安にするには
個人の預貯金を欧米資産に換えることも考えられるが、リスクは肥大化する恐れが強い。
結局、国際経済が不安定のために、リスクマネジメントとして円を求める人が多いので円高は防げない。

日本の課題 その1

日本の課題について
①財政再建
②人口の減少と高齢化
③利便性重視から自然との共存
④労働力のバランス配分

①については、財政赤字、これは抜本的に是正すべきであることは誰でも考えること。
これからの20年が日本の財政にとっては危機的状況であろうことは誰でも理解しうる

②については、高齢化の波と人口の減少は、一気に進む。
また年金の支払力は国家にあるのであろうか？
①から推測して年金の支払いが滞ることが推定できる
人口減少に伴い、税収の確保はできるのかといえば不可能に近い

③については、利便性の重視のために、財政を長期的に利用している高速道路など、さまざまなものが本当に必要かを考えるときである。
利便性重視で自然を破壊し、また、財政赤字に・・・心が豊かにならない社会を望む火う要請がないと考えれば、日本の豊かな観光資源が活かせる。

④については、労働力が減少するのであるから、働ける年齢そして、社会環境を整備する必要がある。バランス配分、働ける人に働いてもらう。
農業、工業などの労働力をバランスよく配分し、教育についても、実務に即した基礎力に重視すべきだ。

また、何かを考えたときに記す。

IT教育ついて①

IT教育について、資格勉強が多い。
なぜでしょう？
・勉強の成果としては、資格のほうが判断しやすい。
・実務に即した勉強をしても客観的評価ができない

となると資格に即した講義になる。
これはわかりやすいのか、はなはだ疑問である。

今後必要な人材を初心から育成すべき時は、4か月ぐらいで、設計から製造、テストまでできる人材の育成である。
どのような視点で育成すべきか、次回に述べる。

あわただしい日々

現在、仕事が集中し、あわただしい。

Webのシステム構築の際、いろいろな視点から考えて、設計・製造をスムーズに行う方法を考えてみています。
価格競争に負けず、また品質なども強化できそう。

経営を考える

4月になりましたので経営について
日本経済はちぐはぐで、何か前を進もうとしない。また、何かについて臆病？になっているように思える。萎縮してしていると言ったほうが正しい。

あまりにも日本経済は前に進まない。机上の空論のようになっている。
①日本の財政および社会インフラが陳腐化についてはアメリカの1980年代が参考になる。同じようなことが起きている。
②円高などの金融政策については、1990年年代の韓国が参考になる。

歴史から学びとって、今の日本の経済を活性化する必要がある。
①過去の技術立国のときのことを考えず、新たな技術立国になること
　・環境システム
　・農業システム
　・林業システム
　・水道システム
　・鉄道システム
　などを再構築して、日本の主流にすることが必要。
産業を立て直しをする。この時必要なのは、全世代を動員し、コミュニケーションを構成することが基本となる。
いろいろな世代間で考えることは違ってもアイデアは各種のものが出てくる

②財政再建
　・収入を考えた支出。省庁の縦ベースの予算ではなく、目的別予算配分
　・赤字になるものを切るのではなく、赤字になっている要因を調べ、黒字化を目指す
　　行政サービスは赤字になることが多い
　・国債依存度を少なくする、もちろん建設国債の発行も減らす
　・デフレにしないシステムにする。過度なインフレは問題であるが、ある程度インフレになっていないと、経済が縮小し、貨幣価値が高くなりすぎるきらいがある。
　・行政が予算執行権を行使する場合、行政監査は国民が行う。
　　行政監査でNGのものは、最後、国会の議決が必要とする。
　　　憲法改正も視野に入れる
　・民間企業が活発になるようにし、法人税などを増やす

③産業については大学を中心として民間企業と一体化させる。
　・産業の技術的進歩と大学の研究としての進歩をさせる
　　たとえば、農業研究を農業試験研究所と大学とで行い、農業の推進
　・大規模農業にするために、農業会社の設立

④震災の被災地を中心に新都市を再構築し、新たな工場などを建設する
　・中心となる産業を育成し、都市を作る
　・弱者に対し、やさしい都市を作る

システム化構想

システム化構想を練っていますが、今一つ、アイデアが出てこない。
といっても、企画しているものは私案としてはいいのですが、もっと快適にかつ大胆なものを作成したいという考えがある。

考えれば考えるほど、よいアイデアがないかと考えてしまう。
これでは・・・

考えることはやめて試行錯誤で作成することにしました。
企画したりして新しいものを作るのは、年齢を重ねても難しい。

教育システム、Webショッピングなど様々なことを考えます。

プログラムの総論

プログラムとは何でしょう？
コンピュータに指示する命令です。
マシン語でもプログラムが可能ですが、とても難しい。

その時使用されるのはプログラム言語といわれるものです。
たとえば、Ｃ言語、JAVA、.Netなどの多数の言語があります。

言語と考えると、このブログを読んでいる言語は日本語ですね。
では日本語には何があるでしょう。
漢字、ひらがな、カタカナ・・・これは日本語の中で使用されている単語です。
そして組み合わせ使用するのは、文法。

ではプログラム言語を覚えるときは
単語と、文法を覚えることが必要になります。

ここから必要な言語を覚えて、プロぐクラムを作成することになります。

プログラム言語については当社ではレジュメの販売や、通信教育を行っています。