Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

POSIX中心主義と情報科学教育

2,305 views

Published on

多数の言語、ライブラリー、ミドルウェア等に依存し、コード保守やサーバ保守で日々泣かされるソフトウェア業界の現状を打開すべく、広い互換性と長い寿命を持った「保存食」のようなプログラムを作る方法と教育の提案

Published in: Software
  • Be the first to comment

POSIX中心主義と情報科学教育

  1. 1. (2) POSIX中心主義と 情報科学教育 USP研究所・金沢大学 共同研究活動報告資料 IoT時代に資するユニケージ開発手法の 普及啓発に関する研究 松浦智之† 大野浩之‡ 當仲寛哲† † ユニバーサル・シェル・プログラミング研究所 ‡ 金沢大学 総合メディア基盤センター 発表日:2016/03/11 スライド最終修正日: 2016/03/12
  2. 2. 本資料について  本資料は、USP研究所と金沢大学の産学連携で実施し ている共同研究活動における成果物の一つです。  本活動の報告を、2016年3月10日~12日に開催され た情報処理学会第78回全国大会における一般セッ ション(3E-05の同題名)で発表し、本資料はその時の スライドと概ね同じ内容です。  一部内容が異なりますが、違いは次のとおりです。  発表時の持ち時間に収めるために削った内容の復活  発表後に寄せらせた質疑・応答の記録の追加
  3. 3. ソフトウェアの問題点
  4. 4. ソフトウェアの問題点 寿命が短い。  (参考)国税庁の耐用年数表  電子計算機は4-5年  ソフトウェアは3-5年 →物理的消耗なき物品の中では短い。
  5. 5. ソフトウェアの問題点 近年、特に短い。  数年、下手すれば半年程度 で使えなくなる。
  6. 6. ソフトウェアの問題点  理由1  高度複雑化に伴う「依存」の加速  「ソフウェア開発=ライブラリ、フレー ムワーク、ミドルウェアの適用」 という作業と化しつつある。
  7. 7. ソフトウェアの問題点  理由2  依存ソフトウェアにおける  後方互換なき機能変更  脆弱性発覚による強制ver. up  サポート終了 の頻発
  8. 8. ソフトウェアの問題点  「サーバ管理者」「システム管理 者」という専門職が生まれ、依存 ソフトのバージョンアップ勧告 に日々泣かされるようになった。
  9. 9. ソフトウェアの問題点  理由3  ソフトウェア開発者側の意識 「ソフトウェアとは短寿命なもの」 →長寿命なプログラムを作る配慮 が忘れ去られがち。
  10. 10. ソフトウェアの問題点  近年のプログラミング実践教育 は、OJTに頼り 表面的で短命な技術 ばかり教えられている。
  11. 11. ソフトウェアの問題点  今覚えた技術は10年持つのか?  10年後に、 10年分の成長ができる技術者は どれだれいるのか?
  12. 12. POSIX中心主義
  13. 13. POSIX中心主義 ― 概要  UNIX系OSにおける最低限の インターフェースを定めた規格 「POSIX」に極力準拠させる プログラミング方針 (用語は我々が独自に定義)
  14. 14. POSIX中心主義 ― 概要  POSIXに準拠させることで、 ソフトウェアは高い互換性と 持続可能性(=長い寿命)を 獲得可能。 ……ソフトウェアにおける保存食を目指す
  15. 15. POSIX中心主義 ― 概要  POSIXの高い互換性の要因  現在、多くのUNIX系OSが準拠している。  明示的準拠……商用UNIX、 Mac OS Xなど  暗示的準拠……FreeBSD、 LinuxなどのPC UNIX  OSベンダーにとって、準拠はメリット  OS間でソフトウェア資産が共有できる。  ユーザにUNIX系OSであると認知され、選択される理由になる。
  16. 16. POSIX中心主義 ― 概要  POSIXの長い持続可能性の要因  国際規格であり、一つのベンダーの恣意的な思惑が反映され にくい。  低水準寄りの規格であり、頻繁な改定は多くのベンダーに副 作用を及ぼすため、できない。  最低限の規定しかされず、ベンダーにとって自由度が高い。
  17. 17. POSIX中心主義 ― 概要 「幅広い環境と時代に 対応できる互換性」  どのUNIX系OSでもそのまま動く。  バージョンアップしてもそのまま動く。
  18. 18. POSIX中心主義 ― 概要  POSIX中心主義を身に付ける際、 より低水準の領域を学ぶ。 ハードウェア ハードウェア ハードウェア カーネル シェル 言語 言語 アプリ アプリ アプリ アプリ アプリ POSIX中心主義と高級言語の学習範囲のイメージ 高級言語の学習領域 POSIXの学習領域
  19. 19. POSIX中心主義 ― 概要  POSIX中心主義での学習内容は、 通用する年月も長い。 POSIX中心主義と高級言語の学習効果のイメージ 現在 1年後 5年後 10年後…
  20. 20. POSIX中心主義 ― 概要 「現場と時代を問わず 頼れる技術者」 (寿命が長いのはプログラムのみにあらず)
  21. 21. POSIX中心主義 ― 方針  3つの具体的な方針 ① POSIX準拠 プログラミング ②交換可能性担保 プログラミング ③W3C勧告準拠 プログラミング 単独ホスト または Webサーバ Webクライアント
  22. 22. POSIX中心主義 ― 方針 ①POSIX準拠  POSIXの範囲で実装する。 POSIX公式情報サイト http://pubs.opengroup.org/onlinepubs/9699919799/
  23. 23. POSIX中心主義 ― 方針 ①POSIX準拠  POSIXには、160個のコマンドがある。 (2013年改訂)  AWK, sed, grep, ……  AWKやsed等、チューリング完全なコマンドを 含む。 → POSIXの範囲で、どんな計算も書ける。
  24. 24. POSIX中心主義 ― 方針 ①POSIX準拠  言語は、基本的にシェルスクリプト  POSIXで規定されているものがそれであるため。  C言語もあるが、バイトオーダ等のハードウェア依存を 意識せざるを得ず、実用性は劣る。 (シェルスクリプトでは、コマンドが吸収してくれる)
  25. 25. POSIX中心主義 ― 方針 ①POSIX準拠  シェルスクリプトはOS依存が激しい?  それはPOSIXを意識せずに書いてしまうから。  OS依存性を避けるため、言語(ライブラリ含む)や ミドルウェア等を選んでも、OS依存に喘ぎながら インストール、メンテナンスしては本末転倒。  依存ソフトが激しく非互換ver. upするせいで、 バージョン依存を起こしてはさらに本末転倒。
  26. 26. POSIX中心主義 ― 方針 ①POSIX準拠  例(1)―日付計算コマンド(utconv)  https://github.com/ShellShoccar-jpn/misc-tools/blob/master/utconv  日常時間←→UNIX時間 相互変換  ほぼAWKで実装  dateコマンドは、OS依存が激しいため再発明 $ echo 2016031112000000 | utconv 6299836182000 $ echo 6299836182000 | utconv –r 2016031112000000 $
  27. 27. POSIX中心主義 ― 方針 ①POSIX準拠  例(2)―XMLパーサ(parsrx.sh)  https://github.com/ShellShoccar-jpn/Parsrs/blob/master/parsrx.sh  XML→行列指向フォーマット(XPath - value)への変換  sed, AWK, tr等、26個のコマンドをパイプで連結し生成。  JSON, CSVパーサも同様に実装済。 <文具購入リスト 会員名="文具 太郎"> <購入品>はさみ</購入品> <購入品>ノート(A4,無地)</購入品> <購入品>シャープペンシル</購入品> <購入品><取寄商品>替え芯</取寄商品></購入品> <購入品>クリアファイル</購入品> <購入品><取寄商品>6穴パンチ</取寄商品></購入品> </文具購入リスト> /文具購入リスト/@会員名 文具 太郎 /文具購入リスト/購入品 はさみ /文具購入リスト/購入品 ノート(A4,無地) /文具購入リスト/購入品 シャープペンシル /文具購入リスト/購入品/取寄商品 替え芯 /文具購入リスト/購入品 /文具購入リスト/購入品 クリアファイル /文具購入リスト/購入品/取寄商品 6穴パンチ /文具購入リスト/購入品 /文具購入リスト ¥n ¥n ¥n ¥n ¥n ¥n ¥n
  28. 28. POSIX中心主義 ― 方針 ①POSIX準拠  例(3)―RDBMS的操作  データは半角空白区切りのテキストファイル持ち  AWK, grep, sort, join等の組み合わせでselect文相当が実現 → SQL文(RDBMS)不要! SELECT MEM."会員ID", MEM."会員名" FROM blacklist AS MEM RIGHT OUTER JOIN members AS BL ON BL."会員名" = MEM."会員名" WHERE BL."会員名" IS NOT NULL ORDER BY MEM."会員ID" ASC; cat blacklist.txt | # 第1列:BL会員ID # sort -k 1,1 | ←会員IDで並替え uniq > sorted_bl.txt cat members.txt | # 第1列:会員ID 第2列:名前 # sort –k 1,1 |←会員IDで並替え join -1 1 -2 2 -v 2 sorted_bl.txt - ←BLの会員IDで joinできない行 のみを抽出 ブラックリストに掲載された会員「以外」を表示するデータ操作 SQL版 POSIX版
  29. 29. POSIX中心主義 ― 方針 ①POSIX準拠  例(4)―URLエンコーディング(urlencode/urldecode)  https://github.com/ShellShoccar-jpn/misc-tools/blob/master/urldecode  RFC文書が示す規格を学習し、コーディング(RFC3986 sec.2.1)  コマンド内の大半はAWKで実装  Web系変換コマンドの大半は、同様に実装可能。 $ echo 情報A 授業 | urlencode %E6%83%85%E5%A0%B1A+%E6%8E%88%E6%A5%AD $ echo %E6%83%85%E5%A0%B1A+%E6%8E%88%E6%A5%AD | urldecode 情報A 授業 $
  30. 30. POSIX中心主義 ― 方針 ①POSIX準拠  その他―POSIXのコマンドで不十分なもの  非Web系  乱数、 mktemp相当、 全角・半角文字相互変換、 排他制御……  Web系  Cookie、 セッション管理、 MIMEマルチパート作成・解読、 Base64、 CGI変数授受…… Webアプリ開発に必要なものまで、概ね作れる。
  31. 31. POSIX中心主義 ― 方針 ②交換可能性担保  POSIXの範囲で実現できないもの  バイナリ処理(非現実的処理速度なため)  ネットワーク処理(コマンドが無く、原理的に不可)  一定条件の元、POSIX外コマンドを認める。
  32. 32. POSIX中心主義 ― 方針 ②交換可能性担保  一定条件とは、「交換可能性」の担保  交換可能性とは?  「現在利用中の実装が、使えなくなっても、同等機 能を有する別の実装に交換できる性質」と定義  (例)  Apache ←→ nginx ←→ lighttpd 等  sendmail ←→ Postfix ←→ qmail ←→ exim 等  cURL ←→ Wget  OpenSSL ←→ LibreSSL  そもそもPOSIX準拠OS同士には交換可能性がある。
  33. 33. POSIX中心主義 ― 方針 ②交換可能性担保  交換可能性担保における注意点  その実装固有の機能に依存してはならない。  (例)  「Apache ←→ nginx ←→ lighttpd」における、 Apacheのプロクシ機能  「cURL ←→ Wget」における、 cURLのファイルアップロード機能 依存した瞬間から、他実装へ交換できなくなる。
  34. 34. POSIX中心主義 ― 方針 ②交換可能性担保  担保したコードの実例(Twitterクライアント) https://github.com/ShellShoccar-jpn/kotoriotoko/blob/master/BIN/twmediup.sh : : # --- 2.HTTPアクセスコマンド(wgetまたはcurl) if type curl >/dev/null 2>&1; then CMD_CURL='curl' elif type wget >/dev/null 2>&1; then CMD_WGET='wget' else error_exit 1 'No HTTP-GET/POST command found.' fi : : curlまたはwgetコマンド 両方の存在を確認。 どちらかがあれば、続行 するようにしている。 Web APIアクセスコマンド 存在確認ルーチン
  35. 35. POSIX中心主義 ― 方針 ②交換可能性担保  担保したコードの実例(続き:Twitterクライアント) : s=$(mime-make -m) ct_hdr="Content-Type: multipart/form-data; boundary=¥"$s¥"" eval mime-make -b "$s" $mimemake_args | if [ -n "${CMD_WGET:-}" ]; then case "$timeout" in '') : ;; *) timeout="--connect-timeout=$timeout";; esac cat > "$Tmp/mimedata" "$CMD_WGET" ${no_cert_wget:-} -q -O - --header="$oa_hdr" --header="$ct_hdr" --post-file="$Tmp/mimedata" $timeout "$API_endpt" elif [ -n "${CMD_CURL:-}" ]; then case "$timeout" in '') : ;; *) timeout="--connect-timeout $timeout";; esac "$CMD_CURL" ${no_cert_curl:-} -s $timeout -H "$oa_hdr" -H "$ct_hdr" --data-binary @- "$API_endpt" fi : wgetコマンドには、ファイル アップロード機能がないため、 curl側でも使わない。 →独自に実装 (mime-makeコマンド) wgetコマンド用、curlコマン ド用に分岐させ、2つの書式を 用意する。 ファイルアップロードルーチン
  36. 36. POSIX中心主義 ― 方針 ②交換可能性担保  例 ― Twitterクライアント「kotoriotoko」  ホストにプログラムをコピーするだけで動作(=インストールが簡単)  https://github.com/ShellShoccar-jpn/kotoriotoko
  37. 37. POSIX中心主義 ― 方針 ②交換可能性担保  その他―POSIXではできなかったこと  日本語メール送信……sendjpmail (sendmailコマンドラッパー)  添付ファイルにも対応  https://github.com/ShellShoccar-jpn/misc-tools/blob/master/sendjpmail  PDF作成 なども…
  38. 38. POSIX中心主義 ― 方針 ③W3C勧告準拠  Webアプリではクライアント側も開発が必須  クライアント側はPOSIXとは無縁の世界  HTML/CSS/JavaScript  そこで、W3C勧告に準拠させる。  W3C勧告は、いわば「POSIXのWebブラウザ版」
  39. 39. POSIX中心主義 ― 方針 ③W3C勧告準拠  W3C勧告のHTML/CSS/JavaScript仕様のみ使用  https://www.w3.org/TR/  個々のWebブラウザ独自の仕様には依存しない。  独自ライブラリも使用しない。  jQuery、その他  W3C勧告の範囲でフルスクラッチする。
  40. 40. POSIX中心主義 ― 方針 ③W3C勧告準拠  Ajax処理も、40行足らずでフルスクラッチできる。  (例)https://github.com/ShellShoccar-jpn/Ajax_demo/blob/master/CLOCK.JS // 1.Ajaxオブジェクト生成関数 function createXMLHttpRequest(){ if(window.XMLHttpRequest){return new XMLHttpRequest()} if(window.ActiveXObject){ try{return new ActiveXObject("Msxml2.XMLHTTP.6.0")}catch(e){} try{return new ActiveXObject("Msxml2.XMLHTTP.3.0")}catch(e){} try{return new ActiveXObject("Microsoft.XMLHTTP")}catch(e){} } return false; } // 2.Ajax通信関数 function update_clock() { var url,xhr,to; url = get_homedir()+'CLOCK.CGI'; xhr = createXMLHttpRequest(); if (! xhr) {return;} to = window.setTimeout(function(){xhr.abort()}, 30000); xhr.onreadystatechange = function(){update_clock_callback(xhr,to)}; xhr.open('GET' , url+'?dummy='+(new Date)/1, true); xhr.send(null); } : : // 3.コールバック関数 function update_clock_callback(xhr,to) { var str, elm; if (xhr.readyState === 0) {alert('タイムアウトです。');} if (xhr.readyState !== 4) {return; } window.clearTimeout(to); if (xhr.status === 200) { str = xhr.responseText; elm = document.getElementById('clock'); elm.innerHTML = str; } else { alert('サーバーが不正な応答を返しました。'); } }
  41. 41. POSIX中心主義 ― 方針 ③W3C勧告準拠  例―Ajax Clock(ボタンを押すたび時刻文字列だけ更新)  http://lab-sakura.richlab.org/AJAX/CLOCK.HTML
  42. 42. POSIX中心主義 ― 作成例  (1) 郵便番号から住所を検索  http://lab-sakura.richlab.org/ZIP2ADDR/public_html/  全国14万レコードからの検索に何秒かかるか?
  43. 43. POSIX中心主義 ― 作成例  (2) ショッピングカート  https://richlab.org/coterie/pfb.html  商品・在庫データをテキストファイルで管理  PayPal決済(Web API)にも対応し、実証実験中
  44. 44. POSIX中心主義 ― 作成例  (3) 鉄道運行状況表示プログラム  http://metropiper.com  東京メトロのWeb APIから車両の現在位置を取得  何駅前まで列車が来ているかわかる
  45. 45. 考察と課題
  46. 46. 考察 ― POSIX中心主義の妥当性  互換性のためのI/F標準化の試 みは、POSIX以外にもいくつか あった。  SSI, MOSI, X/OPEN, OSF など  参考文献  「UNIXの標準化とPOSIX」,斎藤 信男,コンピュータソフトウェア 6(1), 84-92, 1989-01-13  「OSインターフェース標準化の動向」,越田 一郎,情報処理学会研究報告シ ステムソフトウェアとオペレーティング・システム 37, 1-6, 1987-06-12
  47. 47. 考察 ― POSIX中心主義の妥当性  30年近く経った現在、 標準化で最も成功しているのは POSIXと言える。  CiNiiで検索可能な論文における 言及数の比較でも明らか。
  48. 48. 考察 ― POSIX中心主義の妥当性  POSIX規格は、高い互換性、 長い持続可能性(寿命)を持つ ソフトウェア開発のため、 現時点で最も妥当な選択肢の1つ。
  49. 49. 考察 ― POSIX中心主義の評価 ①開発  鉄道運行状況表示プログラムは、 東京メトロのコンテスト応募作品  https://developer.tokyometroapp.jp/  オープンデータ活用コンテスト  2014年開催
  50. 50. 考察 ― POSIX中心主義の評価 ①開発  コンテストは東京五輪を意識し ていた、と言われている。  2020年(=コンテストから6年後)  外国人観光客利便性向上のため スマートフォンアプリまで広く募集。
  51. 51. 考察 ― POSIX中心主義の評価 ①開発  受賞作品の上位、かつ大半は、 スマートフォンアプリが占めた。  http://car.watch.impress.co.jp/docs/news/20150220_689397.html
  52. 52. 考察 ― POSIX中心主義の評価 ①開発  「そのAndroidアプリ、 iPhoneアプリ、 2020年にも動くんですか?」  そもそもAndroidやiOS上で、 6年後も動作を保証できるアプリは作れるのか?
  53. 53. 考察 ― POSIX中心主義の評価 ①開発  実際、既に動かない作品が出 てきている。  https://developer.tokyometroapp.jp/app  ただし、コンテスト終了に伴い、意図的に公開終了 した可能性のある作品も含まれ、すべてではない。
  54. 54. 考察 ― POSIX中心主義の評価 ①開発  POSIX中心主義の本作品は、 今も順調に動作中。  http://metropiper.com/  これまで内容の改修は一切なし。 スマートフォン用レイアウトで動作している様子⇒ (POSIX+W3C勧告のCSSとJavaScriptで実装)
  55. 55. 考察 ― POSIX中心主義の評価 ①開発  保守作業コストの削減が可能  依存ソフトに起因する 運用事故防止の効果も期待
  56. 56. 考察 ― POSIX中心主義の評価 ②教育  コンピュータの本質に近い低 水準領域学習の必要性から、知 識の持続可能性(寿命)も長い。  一般的なUNIX環境やUNIXコマンドの学習、 RFC文書の学習 など
  57. 57. 考察 ― POSIX中心主義の評価 ②教育  知識の再利用性が高い。  問題解決力の高い技術者の 育成が期待できる。
  58. 58. 課題 ― 現状の課題と今後の展開  POSIX中心主義は、提唱して日 が浅い。  互換性・持続可能性に対する検証 を継続する必要性  開発方針を、 より具体化させる必要性  啓蒙・促進・普及活動の必要性
  59. 59. 課題 ― 現状の課題と今後の展開  2016年度前期、 UCI(大学コンソーシアム石川)にて 「シェルスクリプト言語論」 として、授業開講予定  POSIX中心主義の普及を図る
  60. 60. POSIX中心主義 まとめ  互換性と持続可能性、 どちらも高いソフトウェアの開発が可能  互換性と持続可能性の高い低水準領域の 知識を持った技術者も育てられる
  61. 61. 謝辞  POSIX中心主義を発案するきっかけとなったユ ニケージ開発手法を推進するUSP研究所の皆様, そして本手法を支持し,本論文投稿にあたり御指 導くださった金沢大学の共同研究者の皆様に,心 より感謝を申し上げます。  POSIXという高い互換性・持続可能性をもたらす 規格を策定したThe Open Groupをはじめ、貢献 している方々に感謝します。
  62. 62. ありがとうございました ご意見・ご質問があれば、お願いします。
  63. 63. 質疑応答の記録 Q. 開講予定の授業で想定する受講者のレベルは?  ある程度UNIXを知っていることを前提をしてい るため、大学院生やUNIX系の専門課程の学部3,4 年生を対象としたい。  大学コンソーシアム(学外)なので社会人も歓迎。現 場で短命なソフトウェアに日々泣かされている開 発者やシステム管理者とも意見交換をしたい。
  64. 64. 質疑応答の記録 Q. 現在のソフトウェア教育は替わりゆく技術に追従すること を重点に教える傾向があるが、正反対に見える。意見を。  重要視する箇所が正反対という認識は正しい。  低水準領域は応用性も普遍性も高い知識になる。  高水準の教育も大切ではあるが、コンピューターの 本質に近い低水準領域を学習してこそ、替わりゆ く高水準領域の技術も体系的に理解できる。
  65. 65. 質疑応答の記録 Q. 開講する授業デザインをどのように考えているか。あれ ば公開してくれるとありがたい。  発表者(松浦)自身は、開発現場(産学連携の産)の 立場から参加しているため教育の詳しい知識を持 ち合わせていない。  学の立場である、金沢大の先生方の協力のもと考 えていきたい。  ただ、フルスクラッチ開発時、RFC文書の読み解き 作業は低水準領域の学習に大変効果的だと実感し たこともあり、現場から得たそういうノウハウは 盛り込んでいきたい。
  66. 66. 独自の質疑応答想定 Q. 例示した地下鉄アプリは今まで改修無しだが、東京メトロ がAPI仕様や路線仕様を修正したら改修が必要なので、持 続可能性確保の試みは無駄では?  東京メトロ自身が、自社の公式アプリを作るとい う想定で考えてもらいたい。  自社都合による仕様変更のタイミングは自社でコ ントロールできる。  しかし、東京メトロのような大きな企業とて、依存 ソフト開発団体(PHP GroupやMySQLのOracleな ど)に「バージョンアップを待って」とは言えない。  依存ソフトのバージョンはアンコントローラブル
  67. 67. 独自の質疑応答想定 Q. 例示されたXMLパーサなど、公開しているということは利 用(=依存)を促すことであり、矛盾ではないか?  利用する場合、中身を理解しながら使うことが大 事(ブラックボックスなままの使用が不幸を招く)  依存ソフトに不具合があったとしても自分の力で 対処できるよう、次の2つの心掛けが大事 1. どういう原理で動いているか、また動作の癖を理解 し、自分の手足のような感覚を得る。 2. 使いだしたら自分の製作物のごとく責任を持つ。  上記理由により、私が公開しているソフトは基 本的に権利放棄(public domain)している。

×