クロネコヤマトの宅急便“NEKOシステム”開発ストーリーを読んで面白かった部分のメモ

○p23
会計機に適用するためのルールも、コンピュータに適用するためのルールも大きな違いはありません。

○p59
「コンピュータシステムをどう変えるか」としていた発想を変えた
「現在のシステムでは間違いデータが多い、ドライバーが無意識にやる間違いをなくすには、何をしたらよいか」
「新しいシステムを作るのだから楽にならなくては意味がない、楽にするには何をどう変えたらいいのか」

○p67
「情報入力をいかに簡便なものにするかが、システムの一番重要な部分となるのではないか」

○p91
1990年代、「ワークステーション」といえば、UNIX系OSを搭載した「ネットワークに強い専用機」という位置付けで使われていましたが、ヤマト運輸では、「仕事をするコンピュータ」という意味で使っていました。

○p94
現在のワークフローを見直すのではなく、「ビジネスプロセスそのものを変えてしまう」といった発想

○p128
卸問屋を中抜きしたE-ビジネス型の物流モデルが増えています。
中間業者の不在により、消費者へのサービスが低下するというデメリットも生じています。

◎pp.136-141(何度か読む事)
誰のためのシステムなのか

12月18日メモ

○目の前の仕事に全力で取り組む。その姿勢が自らの在り方を決める。
・「To Know(知ること)」は大切、「To Do(成すこと)」も大切、しかしそれらより上にあるのは「To Be(如何にあるべきか)」
・誠実に働いていれば、周囲が評価する
・すると、より大きく、責任ある仕事を任される

Web暗号についてのメモ2

Web1.0の時代とWeb2.0の時代の違い

●情報をやり取りする対象
Web1.0:サーバとクライアントの通信の関係
Web2.0:クライアント同士,サーバとその店子
より複雑な状況でのセキュリティを確保することが必要になった.

●情報セキュリティ技術
Web1.0:通信経路の末端であったサーバを中心に考えるサーバセントリック
Web2.0:取り扱われている情報を中心に考えるコンテンツセントリック

Web暗号についてのメモ

研究会でWeb暗号について聴講したのでメモする。

●素朴な疑問
☆様々な暗号プロトコルは何故使われていないのか.
1.暗号プロトコルの安全性が分かりにくいから?
  証明可能安全な暗号プロトコルが多い→×
2.暗号プロトコルはバージョンアップの頻度が高いから?
  他分野では頻度の高いプロトコルも利用されている→×
3.暗号プロトコルは複雑なアルゴリズムで準備が大変だから?
  ただ通信をするだけなのに非常に準備と手間がかかる→◎
4.セキュリティ対策ソフトとは異なり暗号プロトコル自体はユーザにとって重要でないから?
  暗号演算を行なうアプリを個人PCに入れる人はほとんどいない→◎

●モチベーション
Webには危険がたくさんある.
SSLが広く利用されているが,これだけでは解決できない問題が存在する.
☆Webの世界で暗号プロトコルが利用できるようにしたい!
・目標
 1.なるべく簡単に,汎用的に利用できるもの
 2.全ての端末で利用できるもの(ex. PC,携帯電話,携帯端末,ゲーム機)

●Web上の課題
1.情報は置かれている場所によって守られていること
 ・例えばアクセス制御
2.引用したものが信頼できるのかということ
 ・新聞のソースが信頼できるとしても,それを引用しているブログが信頼できるかは別.
 ・引用だとしながら内容が別物になっている可能性がある.

●既存の解決方法
1.文書管理システムのセキュリティ(ex. マイクロソフトAdobeの署名アプリ)
2.XML暗号やXML署名

●既存のアプローチの限界
1.Webで利用できるように設計されていない.
2.決められた方式以外では使えない.
3.暗号プロトコルは外部からプリミティブに読み出すことを許可していない
☆汎用に,かつ手間を少なくやりたい

●提案
Web暗号 JavasCrypt
JavaScriptで暗号演算するための基本ライブラリ
・鍵発行と鍵管理サーバはAjaxを仕様

JavaScript
インタプリタスクリプト言語
ネイティブコードの1000倍遅い
JIT(ジャストインタイムコンパイラ)を実装したブラウザ(ex. GoogleChromeFireFox)でも100倍程度

●Web暗号はどのようなものに使えるか
1.Googleカレンダーに秘密の予定
 ・Googleカレンダーのアクセス制御は,カレンダー単位や人単位でしかできない
 ・この予定は友人と共有したいが同僚とは共有したくないということは難しい
2.Webメーラーでメールを送るときの暗号化
 ・*WebメーラーJavaScriptを動かす事が危ない?らしい
プラグインを使うのではなく,既存のドキュメントの中に追加することで応用が進むのではないか

●質問
A1.
 鍵の管理はどのように考えているか
Q1.
 鍵管理は2種類ある
 1.自分の鍵を見せないように守る
  →クッキーの中に入れる
 2.持っていてはいけない鍵を持たせない
  →プログラム以外でも認証するようにしたい
   サーバの中にも鍵がある秘密分散をすることで,サーバにアクセスして残りの鍵を手に入れないと鍵として使えない。
  →オフラインであるという状況は想定しない

A2.
 JavaScriptで記述された暗号プロトコルはソースが見えてしまうが問題はないのか
Q2.
 暗号プロトコルであるので見られても問題はない

A3.
 ソースの内容を書き換えられても問題はないのか
Q3.
 書き換える側にメリットがないので大丈夫。←そんな理由でいいのだろうか

A4.
 JavaScriptのデータサイズが大きくなって重たくなるのではないか
Q4.
 サイズは1K程度でナローバンドの世界ではないので気にならない程度
 処理時間のほどんどが暗号演算の部分

A5.
 ScriptなのでVMの性能に引っ張られるのではないか
Q5.
 実際に引っ張られる
 各ブラウザでの処理時間は次の通り
 1.InternetExplore:478msec
 2.Firefox:194msec
 3.GoogleChrome:16msec

一般ユーザがsudoコマンドなどのシステムコマンドを使う方法

$ sudo ifconfig -a
としてもifconfig: command not foundと表示されるので調べてみた。

sudoコマンドの注意点は環境変数が一般ユーザーのままである点です
つまりシステムコマンドのディレクトリーにはパスは通っていません

$ sudo /sbin/ifconfig -a
などフルパスで指定します

http://usednote.seesaa.net/article/40411090.html

ちなみにDevianやUbuntuだとフルパスの必要はないそうです。
/sbinへのパスを通せば同じようにできるのかな。

i430Tでアプリケーションを実行させる手順のメモ

下のサイトを参考。
http://www.xscale-freak.com/reports/idyreport/android2
http://www.idy-design.com/product/up_file/1248939562-789637.pdf

CentOS5.3を使って実行させる手順をまとめる。

1. tftpのインストール

% yum install -y tftp

2. 作成したapkファイルを/tftpbootに移動させる
*i430TのSDKのバージョンと一致したapkファイルを使う事。
*手持ちのi430Tのバージョンは1.5
*apkファイルは /workspace/プロジェクト名/bin/○○.apk にある。

% mv HelloAndroid.apk /tftpboot/HelloAndroid.apk

3. iptablesの停止(必要ないかも)

% /etc/rc.d/init.d/iptables stop

4. SeLinuxの停止(必要ないかも)

% setenforce 0

5. usb0のIPアドレスを192.168.1.100 に設定
CentOSの入ったPCとi430TをUSBケーブルで接続した後以下のコマンドを入力

% ifconfig 192.168.1.100
上手くいかないときはUSBケーブルを抜き差しするかPCを再起動

6. Telnetでi430Tに接続

% telnet 192.168.1.103

7. 作成したapkファイルを書き込む


% cd /data/app
% tftp -l HelloAndroid.apk -r HelloAndroid.apk -g 192.168.1.100
% exit

8. i430Tで実行させる
USBケーブルを抜いて、アプリケーション一覧を表示(△ボタンを押す)
HelloAndroidをクリックして実行