職場の組織が変わって、職場の方のホームページを更新しなければいけなくなったのが発端なのですが、同僚と会話していて、ぼそっと「なんか昔のホームページだよねー」と言われてしまったので、ホームページ作成のバックエンドを更新しました。
もともと割とブラウザを選ばないように、またレイアウトも画面サイズに柔軟に作っていたのですが、ここ5年位で急速にWebの古い環境が消え去っていったので、一気に HTML5 + CSS3 ベースに更新するとともに、モバイル環境に正式対応することにしました。
とはいえ、静的コンテンツしか置けないような環境もあるので、システムの基本の作りは変わっていません。
今回、自分の記録を兼ねて、過去のデータを調べなおしてみました。WayBack Machine をみると、(今となっては恥ずかしい)データがいろいろ残っています。
2018/12/12
2018/11/26
make-password: パスワード生成ツール 公開
職場の方に、パスフレーズ生成ツールとライブラリ、実働デモサイトを合わせて公開しました。
職場で色々な人と仕事の文書をやり取りする際、最近では暗号化は当然のことになっていますが、みんな作るパスワードがどうしても緩いものになりがちでした。さらに、パスワードを次のメールで送るという悪癖も、大変気になります。
とはいえ、100ビットとかの強いパスワードを手で作るのは結構大変で、それを会議の参加者で共有するのも大変面倒でした。会議室のWi-fiパスワードでも面倒くさいと思った人は多いはず。
というわけで、職場でこれを見直し、周りの関係者も巻き込んでいくには、色々工夫しないとダメだぞ、ということで、それにはリファレンスとなるツールをきちんと開発しないといけないね、と。
作ったツールですが、まずはデモサイトを見てもらうのが早いかもしれません。
ツールに世の中の単語の辞書をいくつか内蔵していて、
- ランダムな文字の組み合わせ
- ランダムに選んだ英単語の列
- ランダムに選んだ日本語の列
などを自由に選んで組み合わせられます。
これで、「打ちづらく間違えやすいけど、短いパスワード」と、「長いけど読みやすく間違えにくいパスフレーズ生成」の、好きな方を選ぶことができます。特に日本語の場合はローマ字だけでは読みづらいため、元の単語もヒントとして一緒に表示できます。また、パスワードの強度も数値で指定して、それに合わせた文字数・単語数を自動的に選びます。
これで、「打ちづらく間違えやすいけど、短いパスワード」と、「長いけど読みやすく間違えにくいパスフレーズ生成」の、好きな方を選ぶことができます。特に日本語の場合はローマ字だけでは読みづらいため、元の単語もヒントとして一緒に表示できます。また、パスワードの強度も数値で指定して、それに合わせた文字数・単語数を自動的に選びます。
PDFイメージ |
また、パスフレーズ生成部分は独立して使えるライブラリにしたので、応用して上手いワークフローを考えて貰えると嬉しいです。
最近の計算機が速くメモリが潤沢になっても、10万語クラスのテキストの読み込みは一瞬(0.5秒くらい)止まるので、その辺りはちょっと工夫してあります。
ちょっとずつ世の中の慣習が、良い方向に変えられるといいなぁ。
2018/11/23
hex-m17n: 多言語対応のダンプツール 公開
hex-m17n: 多言語対応のダンプツール を公開しました。
日本語のLinux環境はどうしても多種多様な文字コードが入り混じるものですが、日本語含むバイナリファイルを文字化けさせずに読むために、1996年頃にに大学の先輩の多賀さんが作られていた hex というツール が当時はすごく便利で、愛用していました。制御文字を単に 「.」 で表示するのではなくて、色分けしてそれなりに判りやすく表示してくれるのがすごくお気に入りでした。
でも、その後すっかり UTF-8 が標準になって、自分のコンソールもUTF-8化して、他の文字コードや言語も色々と扱うようになったので、これは自分で欲しいものは自分で作ってしまおう、と思って2年前に一気に書き上げたものです。
今時作るからには ISO 10646-1 / Unicode ベースで作ることになるのですが、
作り上げてから自分で愛用しつつ2年くらい放置していたのですが、この際 github 周りを色々整理したので、いっそのこと公開することにしました。
説明のWebページはこれから作りますが、とりあえず github に README を上げておけばいいよねと、ずいぶん気楽な時代になったものです。
日本語のLinux環境はどうしても多種多様な文字コードが入り混じるものですが、日本語含むバイナリファイルを文字化けさせずに読むために、1996年頃にに大学の先輩の多賀さんが作られていた hex というツール が当時はすごく便利で、愛用していました。制御文字を単に 「.」 で表示するのではなくて、色分けしてそれなりに判りやすく表示してくれるのがすごくお気に入りでした。
でも、その後すっかり UTF-8 が標準になって、自分のコンソールもUTF-8化して、他の文字コードや言語も色々と扱うようになったので、これは自分で欲しいものは自分で作ってしまおう、と思って2年前に一気に書き上げたものです。
今時作るからには ISO 10646-1 / Unicode ベースで作ることになるのですが、
- 「読みやすい od -c 相当の機能が欲しいよね」とか、
- 「そもそも『文字化けしない cat』が欲しいだけなんだよね」、とか
- 「今時日本語だけ対応のフリーソフトってどうなんだろう」とか、
- 「2000年頃に自分がこだわっていた、ISO 2022 ベースの多言語化はきちんと対応させたいよね(ISO 2022 で多言語化した昔の文書ファイル、未だに結構持ってるんです)」とか、
作り上げてから自分で愛用しつつ2年くらい放置していたのですが、この際 github 周りを色々整理したので、いっそのこと公開することにしました。
説明のWebページはこれから作りますが、とりあえず github に README を上げておけばいいよねと、ずいぶん気楽な時代になったものです。
2018/11/17
近況...
ブログをそろそろ復活させようとするにあたって、思い切ってクラウドサービス化してみました。
以前の「日記」の2014年の関西転勤から、
「つくば再転勤&研究企画室勤務」「情報技術研究部門への統合」などを経て、
この11月から産総研 サイバーフィジカルセキュリティ研究センター が立ち上がり、
「ソフトウェア品質保証研究チーム」という新しいチーム名で引き続き研究リーダーを勤めることになりました。
研究テーマは大きく2つ、「AIソフトウェアの品質保証 (quality assurance)」と「実世界とソフトウェア品質の関わり」になります。この大きなお題目の中で、引き続きネットワークセキュリティやIoTセキュリティについても取り組みを続けていきます。
「AIソフトウェアの品質保証」は、実践的でニーズベースの研究活動であると同時に、私のソフトウェア科学者としての「良いソフトウェアって何だっけ」という永遠の問の解答探しの1つでもあると思っていて、結構わくわくしています。
「機械学習で作られたAI」というのは、「所詮はソフトウェアの一種」でもあり、「従来とは全く作られ方の違うソフトウェア」でもあります。「ソフトウェア工学」というのはいわば「作り方」の工学でもあり、作り方が変わったときに、これまでの常識の何が通用し何が通用しないのかというのは、「常識を分析して再構築する」という非常に面白い探求ネタになります。
「ソフトウェアを正しくする」ということについて、ソフトウェア作りの現場の視点と、ソフトウェア工学的視点、ソフトウェア科学の理論的視点はどれも微妙に違う視点を持っている気がしていて、なりゆきでそれら全てに触れてきた自分として、これらの視点の違いに自分なりの説明を作る良い機会なんじゃないか、と思っています。かつての「理学部情報科学科卒」「情報理工学系研究科修了」という両方にこだわりのある私にとっては、「工学(人の営み)を科学(合理的な理論)で説明する」ってのはとても楽しいチャレンジなのです。
また面白いことを色々できればな、と思いますので、適当にお付き合い頂ければと思います。
以前の「日記」の2014年の関西転勤から、
「つくば再転勤&研究企画室勤務」「情報技術研究部門への統合」などを経て、
この11月から産総研 サイバーフィジカルセキュリティ研究センター が立ち上がり、
「ソフトウェア品質保証研究チーム」という新しいチーム名で引き続き研究リーダーを勤めることになりました。
研究テーマは大きく2つ、「AIソフトウェアの品質保証 (quality assurance)」と「実世界とソフトウェア品質の関わり」になります。この大きなお題目の中で、引き続きネットワークセキュリティやIoTセキュリティについても取り組みを続けていきます。
「AIソフトウェアの品質保証」は、実践的でニーズベースの研究活動であると同時に、私のソフトウェア科学者としての「良いソフトウェアって何だっけ」という永遠の問の解答探しの1つでもあると思っていて、結構わくわくしています。
「機械学習で作られたAI」というのは、「所詮はソフトウェアの一種」でもあり、「従来とは全く作られ方の違うソフトウェア」でもあります。「ソフトウェア工学」というのはいわば「作り方」の工学でもあり、作り方が変わったときに、これまでの常識の何が通用し何が通用しないのかというのは、「常識を分析して再構築する」という非常に面白い探求ネタになります。
「ソフトウェアを正しくする」ということについて、ソフトウェア作りの現場の視点と、ソフトウェア工学的視点、ソフトウェア科学の理論的視点はどれも微妙に違う視点を持っている気がしていて、なりゆきでそれら全てに触れてきた自分として、これらの視点の違いに自分なりの説明を作る良い機会なんじゃないか、と思っています。かつての「理学部情報科学科卒」「情報理工学系研究科修了」という両方にこだわりのある私にとっては、「工学(人の営み)を科学(合理的な理論)で説明する」ってのはとても楽しいチャレンジなのです。
また面白いことを色々できればな、と思いますので、適当にお付き合い頂ければと思います。
登録:
投稿 (Atom)