A&Eソフトラボ開発日記: 8月 2015

2015年8月31日月曜日

Dockerのデータのポータブル化

Dockerコンテナの永続化についてです。
本来、ポータビリティの高い、あるいは、ポータブル化が主目的であるはずのコンテナでいかに永続化するのか、ある種のパターン化したソリューションの紹介です。

たとえば、MySQLをコンテナとして起動します。コンテナを stop させれば、当然ながら蓄積されたレコードは跡形もなく消えてしまいます。
そこで、よく用いられる手法が、データをホストのディレクトリにマウントする方法。

sudo docker run --name=mysql-data -d -v /opt/data/mysql:/var/lib/mysql foobar/mysql:latest

ボリュームオプションにより、ホストの /opt/data/mysql/ に記録しようと企てています。
しかし、この方法だとコンテナ自体のポータビリティが損なわれ、ほかのホストへの移植に際して考えなければならないことが増えてしまいます。
当然ながら、開発環境とテスト、本番などの差異を吸収するのが困難になります。

そこで、MySQLコンテナとは別にデータを永続化するコンテナを作成する方法をとってみます。
Dockerfileを作成します。
今回は最小限の構成で作成されている公式のイメージ busybox を使用します。

FROM busybox
VOLUME /opt
CMD /bin/sh

このDockerfileをビルドします。
$ sudo docker build -t foobar/mysql-storage:1.0 /opt/data/mysql

完了したら sudo docker images で確認します。

次に永続化用データコンテナを起動します。
$ sudo docker run -i -t -v /opt --name mysql-data busybox /bin/sh

ボリュームオプションで /opt以下を格納するコンテナになります。

では、このコンテナを使う側から見ます。
$ sudo docker run -t -i --volumes-from mysql-data mysql /bin/bash
--volumes-fromで件のコンテナのディレクトリを参照して起動します。これで件のコンテナとつながりました。

/opt 以下が接続されたのか確認します。
/# ls -al /opt/

本来のマイクロサービス、あるいは、一定の粒度をもったSOAアーキテクチャの設計パターンでは、このような Dockerソリューションの隔離されたうま味を十分に生かせるような発想が重要になってくるはずです。

2015年8月29日土曜日

Expressであえて静的なファイルを生成してみる

たとえば、以下の2種類のJade定義を用意します。

1) base.jade:

doctype html
html
head
title= title
link(rel='stylesheet', href='/stylesheets/style.css')
body
block content

2) extend.jade:

extends base

block content
h1= title
p Welcome to #{title}

これは、2）のHTML出力用に定義した extend.jade をテンプレートとして、これから HTML を生成しようと思います。
しかし、上記には構造上のちょっとした工夫があって、extend.jade は、1）の base.jade を継承しています。
具体的には、おおまかなレイアウトは base.jade が担い、body の部分を extend.jade に差し替えています。
それが、block content という記述です。

さらに、Nodeのほうでは、HTML をレンダリングするのではなく静的な HTML ファイルを物理的に生成しようと思います。
それが次のコードです。

まずは、ルーティングの部分にRESTのPostリクエストを、app.js に記述します。
var output = require('./routes/output')
app.use('/output/:param', output);

次に処理の部分を output.js に記述します。
var express = require('express');
var router = express.Router();

var jade = require('jade'),
fs = require('fs');

/* POST listing. */
router.post('/', function (req, res) {

　　//　事前条件は省略・・・

fs.readFile('./views/extend.jade', 'utf8', function (err, source) {
if (err) throw err;
console.log(source);
var opts = {
pretty: true, filename: './views/base.jade'
};
var template = jade.compile(source, opts);
html = template(body);
fs.writeFile('./public/test_file.html', html);
});

　　// レスポンス処理は省略・・・
});

module.exports = router;

通常、このようなコードを書くことはないと思いますが、実験です。あえて静的なHTMLをレンダリングするのではなく実体を出力します。
ポイントは、jade.compile() の第2引数として与える opts のパラメータに jadeの継承元のファイルを指定してあります。

では、POSTでリクエストします。URLはこんな感じです。当然 JSONプロトコルです。
http://XXX.XXX.XXX.XXX:YYYY/output/param

そして body はこんな感じ。
{
"title": "test_parameter"
}

生成された HTML ファイルは以下のようになります。
<!DOCTYPE html>
<html>
<head>
<title>test_parameter</title>
<link rel="stylesheet" href="/stylesheets/style.css">
</head>
<body>
<h1>test_parameter</h1>
<p>Welcome to test_parameter</p>
</body>
</html>

という検証結果でした。
今回はノンブロッキングIOに関する考察は省略しましたが、この部分は注意してください。

2015年8月27日木曜日

Buzz

BuzzFeedが今冬にも、いよいよ日本にも上陸します。
政治経済からサイエンス、芸能まで幅広く、そして名前のとおりBuzzっているニュースが日本のユーザにはかなりアピールするのでは？と予想しています。
Googleの検索系とは違うバイラルメディアに中毒状態になる人も続出するかもしれません。

ここでバイラルメディアに関して簡単に書いておくと、Web流入を目指したSEO対策などの検索コントロールとは違う、いわゆるソーシャル系の拡散情報が集約されるメディアです。
簡単に言ってしまえば、いわゆるまとめ記事的なものです。
もちろん、有益なものも多いと思いますが、そのほとんどがBuzzったゴシップ記事かもしれません。
ニュースの形式もどんどん新しくなっていきます。そしてカバーする枠組みもどんどん拡大していくのかもしれません。
私たちは、その情報の洪水の真っ只中で、溺れていくのでしょうか。

2015年8月26日水曜日

積極的に「できない」と言う感性

「XXXなはず。」
「XXXXは、ここでは有り得ないこと。」

上記のセンテンスは、一日に何度も聞く言葉です。
これらは、常に根拠なき推測に基づいた表現手段です。
メカニズムというのは感情や理性を持っていませんから、このような判断をすべきではありません。
言ってしまえば、これらは性善説に基づいた単なる願望に過ぎません。
私たちの仕事はいかなる状況においても常にロジックで判断をして、裏付けをとり、根拠を明確にしないとならないのです。

「できないこともないけど…」
これも何度となく耳にする発言です。
バリエーションとして
「できないこともないけど、工数が足りない。」
「できないこともないけど、人が足りない。」　などがあります。

これらも似たような構造で、きっとできるはずという願望が見え隠れしていて、根拠が示されていません。
根拠には次の2つの特性が含まれます。
ひとつには、過去の経験から得た知見に照らし合わせて、どのくらいで解決できるだろううか？　あるいは、解決が可能であるか？　という視点。
ふたつめは、自分の経験に参照することができずに一定の調査や学習が必要だと判断できる視点です。

とくにふたつめの視点は大切です。
常に一定の解決手段でものごとを進められるほど、仕事は単純ではありませんし、安定稼働や合理性という観点を損なうわけにもいかないからです。
したがって、エンジニアとして純粋無垢である姿勢が問われるのです。言ってみれば、これは伸びしろでもあります。

「できない」と「やるべきでない」がクロスオーバーしたときに、きっと重要なポリシーを発見できるのではないかと思うのです。

2015年8月25日火曜日

サンプル実装

プロトタイプを作る。と読み替えてもらってもよいです。
よく機能の検証や、画面の動きや連携などでサンプルを作成する機会があると思います。
このときに、どのように作るでしょうか？
どうせサンプルなのでという考えで、ざっくりと画面直下やビハインドコードに押し込めてしまったりしていませんか？
この方法だと結局作り直すことになってしまいます。その作り直し方も切り貼りが中心になり、データのハンドリングで苦労して、結局時間を浪費することになってしまう可能性が高いです。もっと悪いことに偶然動いてしまい、深刻なバグの表出の発見が遅れてしまうことにもなりかねません。

サンプル実装とは言え、手を抜くべきではないです。
したがってあえてプロトタイプと読み替えても構わないということを書きました。
実はサンプルだからこそ、しっかりと検証すべきなのです。ここでいう検証はアーキテクチャや設計、パターン、抽象化、データの表現、通信などが含まれます。
つまりシステムに関するほとんどの現象がこのときに確認されるべきなのです。
しっかり作りこんでしまったら本番と変わりなくなってしまうではないか？　という意見も当然ながら出てくると思います。
ここで検証すべき本質はデータのハンドリングの妥当性、アーキテクチャのバランス、また、とくに通信系は本当に接続が可能なのか？という点について入念に検証すべきです。

ここまできて気がついた方は多いかもしれませんが、サンプル実装（プロトタイプ）は、ほとんど本番です。プロトタイプで幾十にも検証されて本番に発展してゆくのです。ここで検証の状態や意図した設計がよくなければほかの手段を検討することになります。
このプロセスの段階で再検討は許容範囲です。この段階でしっかり根拠をつかむことなく、いい加減な状態で本番実装に入ると、ある程度実装が進んだ段階で問題が発露します。
これは、いわゆる手遅れの状態です。
ここで本来の姿に戻すには、結局ごまかすか、作り直すか、の選択になると思います。

結局、プロトタイプの考え方が生産性や安定性に大きな影響を与えるのです。

よく、こんなことを聞きませんか？
「これで、きっと出来るはず。」
これは根拠のない、ただの願望です。

2015年8月24日月曜日

Bootstrap 4 alpha リリース

オープンソースのCSSフレームワークである Bootstrap の最新版 Bootstrap 4 alpha がリリースされました。
JavaScriptプラグインを全てECMAScript 6仕様でリライトする変更が加えられています。

Bootstrap 公式ブログ

メタ言語の採用は、LESSからSassに移行しました。
グリッドシステムは、12列のレイアウトに基づいて、複数の層、各メディアクエリ範囲のいずれかを有していますが、従来の4種類の表示調整（xs、sm、 md、lg）に加えて、480px以下のスクリーンに対応する xl が追加されました。

また、クロスブラウザのレンダリングのCSSリセットとして、Normalize.css を拡張し Reboot.scss に統合されました。

そして最も大きなトピックであろうと思われるのはIE8へのサポートを終了したことです。
つまり、レスポンシブデザインを実装するために重要なCSSメディアクエリをサポートしないIE8を切り捨てたことになります。
<meta> タグには可能な限り
<meta http-equiv="X-UA-Compatible" content="IE=edge">
と記述するか、あるいは、検討が必要です。

モバイルファーストのレスポンシブWebな方は要チェックです。

2015年8月22日土曜日

週休三日

ユニクロなどを展開するファーストリテイリングが10月から希望者を対象に週休三日を導入する、というニュースが、昨晩の深夜帯のNHKのニュースでも取り上げられていました。
週の労働時間は変えずに、5日の出勤を4日に圧縮する合理化策です。
個人的には歓迎すべきニュースで、この流れが加速してひとつのムーブメントにまで醸成されれば、日本も少しは幸せになるのでは、と淡い期待を寄せています。
実は、スポーツ用品などを扱うアルペンは1989年に既に週休三日を導入してます。ずいぶんと早い時期から労働時間の圧縮を実施していたのですね。
もう少し後になるとEPSONが製造現場での裁量制的な製造活動を実現しています。
一部ではありますが、日本もこのような流れの努力をしているのです。

とはいえ、基本的に我々日本人は働き過ぎだと思います。単なる働き過ぎではなく、働き過ぎに感覚が麻痺しているとさえ思います。とくに私たちの業界がその最たるものではないでしょうか。ここに改善の余地はないのでしょうか。
インターネット黎明期、私たちのような職種はやはり働きすぎでした。しかし、いまほど働いていなかったように思います。あれから、約20年。モノづくりの手法も考え方もツールもずいぶん合理的になったのにもかかわらず、いまのほうがずっと働き過ぎなのは不思議ではないですか？

どこに問題があるのでしょうか。

ひとつには、システムが複雑になり過ぎたというのはあると思います。工学的なシステムだけの話ではなく、社会も、サービスも、人も、複雑になり過ぎました。
それは加速度的な速さで拡大しているとさえ思います。
しかしながら、高効率な生産性を目指すプロジェクトもなかには存在します。反面、前時代的な大仰なモノ作りをするプロジェクトも存在します。
どちらが正しいか？という話ではありません。
ただ、幸福を追求する権利と、幸せを感じようとする感性を忘れないで欲しいと思うだけなのです。

2015年8月20日木曜日

Jadeを試す

今回はJadeを試してみます。
Jadeは、HTML を書くための軽量マークアップ言語であり、JavaScript テンプレートエンジンでもあります。
JadeはnodeのMVCスタックのViewの標準レンダラとして採用されている知名度の高いエンジンです。
その最大の特徴は記法にあります。

なんといっても、タグを閉じない。
class と id 属性の記法が CSS セレクタの記法と同じです。
ただし、注意点としてインデントが必須です。これは厳密です。4spaceでもTabでも構いません。必ず統一性を確保します。

では、nodeがインストールされている前提で、npmでjadeをインストールします。
今回は Windows でやってみます。

$ npm install -g jade
C:\Users\xxx\AppData\Roaming\npm\jade -> C:\Users\xxx\AppData\Roaming\npm\node_modules\jade\bin\jade.js
jade@1.11.0 C:\Users\xxx\AppData\Roaming\npm\node_modules\jade
├── character-parser@1.2.1
├── void-elements@2.0.1
├── commander@2.6.0
├── jstransformer@0.0.2 (is-promise@2.0.0, promise@6.1.0)
├── mkdirp@0.5.1 (minimist@0.0.8)
├── constantinople@3.0.2 (acorn@2.3.0)
├── with@4.0.3 (acorn@1.2.2, acorn-globals@1.0.5)
├── clean-css@3.3.9 (commander@2.8.1, source-map@0.4.4)
├── transformers@2.1.0 (promise@2.0.0, css@1.0.8, uglify-js@2.2.5)
└── uglify-js@2.4.24 (uglify-to-browserify@1.0.2, async@0.2.10, source-map@0.1.34, yargs@3.5.4)

以下のようなファイルを作ります。
index.jade

doctype html
html
head
meta(http-equiv="content-type",content="text/html; chaeset=utf-8")
meta(name="description",content= "コンテンツ")
meta(name="keywords",content= "キーワード群")
meta(http-equiv="imagetoolbar",content="no")
title Jadeのサンプル
body
h1 大見出しです
h2 中見出しです
p Jadeを試してみます。

htmlにコンパイルします。
$ jade index.jade

次のようなhtmlファイルが生成されます。

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; chaeset=utf-8">
<meta name="description" content="コンテンツ">
<meta name="keywords" content="キーワード群">
<meta http-equiv="imagetoolbar" content="no">
<title>Jadeのサンプル</title>
</head>
<body>
<h1>大見出しです</h1>
<h2>中見出しです</h2>
<p>Jadeを試してみます。</p>
</body>
</html>

どうでしょうか。
案外、簡単だったと思います。
ちょっとしたサンプルを作ろうとか、大量に静的なページを作るといったようなシーンに活躍すると思います。
nodeでMVC + RESTfulを達成するExpressionを使用するには必須です。

興味を持たれた方は、調べて深みにはまるのもいいでしょう。

2015年8月19日水曜日

仕事力

優れたエンジニアとはどのような人のことを言うのでしょうか？

スキルが高い人！

と一般的には思われている、あるいは、望まれているかもしれませんが、自身はこのような意見に積極的には賛成できません。
なぜなら、スキルだけではモノは作れないと思うからです。
誤解のないように書いておくと、ここで言うスキルとは教科書的な模範的スキルのことです。
次にでてくるのは

人間力？

人によっては政治力？

このあたりは要求は高いと思いますが、ちょっと視点がずれてくるような気もします。
では、スキル = 技術力とひとまず仮定義して考えてみたいと思います。技術力は一朝一夕で当然身につくわけでもなく、まずいかなる分野においても準備が必要です。準備にもいろいろな種類があり、基礎的な範疇にまつわる技術素養がまず必要です。これは地道な努力の積み重ねにより堆積してゆく養分みたいなもので、この部分がしっかりしていれば、いろいろな展開に対して柔軟なアプローチが取れます。
当然、この部分に安住してしまうとどんどん考え方が古くなり、技術の進歩についていくのが難しくなってしまうというリスクはあります。このような現象に対する有効な手段が次のステップです。新しい技術や考え方の摂取です。もちろん、世の中の流れにのる、いわゆる時流や流行に敏感であるべきという種類のことではなく、日々、個々が課題として抱えている問題の半年先や1年後を、あるいは、もう少し先を見据える技術です。こちらのほうが準備と捉えるとわかりやすいと思います。
乗り越えどころというのは急にやってくるわけではなく予兆なり流れが必ずあります、これは個人個人で性格の異なる流れだと思います。この流れ、つまり　ビジョンを持ち続けてどのように進んでいくか？　という展望を思い描けることが重要なポイントでもあり、また　重要な技術力でもあるわけです。
このステップにまで突き進んでいくには、旺盛な知的好奇心とチャレンジ力が必要不可欠になります。とくに前者は感性に属する初動で柔軟に、かつ、いかに物ごとに感動し得るか？　というような繊細さも必要ではないかと思います。

これらのことを、自身は「仕事力」と呼んでいます。

実は、仕事力を語るには、もうひとつ大事な視点があると考えているのですが、それはまた別の機会に書こうと思います。

2015年8月18日火曜日

喜びの瞬間を捉えよう

Googleを語った書籍の広告が、JRの車内にありました。
ここではあえてその内容には触れませんが、購買力をあげるなかなか興味深いコピーがならんでいます。
昨日のニュースでは、Googleの共同創業者でもありCEOのラリー･ペイジが新しい会社を起業し、その傘下にGoogleを置くという話題がありました。
Googleは巨大になり過ぎたのです。

さて、仕事は楽しいですか？
もしかしたら、大半の人が冗談じゃないと声を荒げるかもしれません。

では、コードを書くのは楽しいですか？
またもや、もうへとへとだよ。深夜帯も休日も返上してコードを書いていて楽しいわけがない。という声をあるかもしれません。
仮にある刹那を切り取ってみましょう。きっと生き生きとコードを書いている瞬間が必ずあるはずです。食事を摂るのもわずらわしいほどにタイピングの指の動きが止まらない瞬間があるかもしれません。もし、そのような瞬間に幸運にも出会えたら、あるいは、心当たりがあるならば、そのボルテージの高まりへのストーリーを想像してみてください。

また、このように捉えることも出来ます。
私たちは日々コードを書き続け、クラスを定義し、組み合わせ、そして走らせるわけです。もっとも緊張する瞬間ですが、想定どおりの動きを目の前で展開された瞬間は、きっと喜びに満ちているはずです。

2015年8月17日月曜日

MBA教材としての清掃サービス

新幹線の車内清掃サービスをご覧になったことがある方は、もしかすると案外多いのかもしれません。
いまや世界的にも注目されているこの仕事は、ハーバード大の経営大学院の教材としても取り扱われるほどです。
以前は、3K職場などと揶揄された時代もありました。
清掃の現場はカーテンで閉ざされ、クローズされた車内空間で戦闘が繰り広げられていました。これが、以前のメンタリティなのです。ところが、現在ではひとつのパフォーマンスとして捉えることが可能なほどに、メカニカルで想像力溢れる作業効率を実現、かつ、追及して7分間の Show としてまとめられています。この変化はどこから来たのでしょう？
米流に考えるならば、成果を上げれば報酬で評価し、あるいはその逆であれば罰則を強化する。ところが我が国の文化はまったく違ったようです。新幹線の車掌も、あるいはグリーンアテンダントも清掃スタッフも、お客様に見られることを意識したマインドセットを重視したそうです。これは、オープンであることの重要性だと思います。
しかしながら、ここまでの技術に昇華するには様々な紆余曲折があったことは容易に想像できます。ここにポイントが隠されてると思います。経営サイドや運営陣ではなく、現場から能動的に発信される改善案には必ず明確な根拠があることの重要性を、しっかりと受け止めるまでに成熟した文化が根付いたことの証だと思います。私たちもそこから学ぶべきことは少なくないはずです。

2015年8月6日木曜日

抽象的な工場の提案

ファクトリ（Abstract Factory）は極めて応用力の高い実装パターンです。
昨日にも書いたように、もし、if文の入れ子構造があまりにも深いのであればリファクタリングの兆候です。
同様にif文のコンビネーションの中で階層表現として扱われる問題は、結局は同じシリーズであるわけです。ただ、ほんの少しだけ条件が変わるだけなので、そういう場合は頭を冷やすなり、もう一歩引いた視点で俯瞰する必要があります。

これは決して難しい問題ではありません。
たとえば、ある車を生産する工場があったとします。その工場ではたったひとつの車種を生産します。しかしながらオプションの種類が多彩で、その都度生産条件を変更してやる必要があります。まさに if文で判定するわけです。
しかし、その方法ではおそらくすぐに限界がやってきて作業ミスが多発する問題は避けがたくなるだろうと思われます。
この問題をどのように回避したらよいでしょうか。

先にも書いたように、もし○○○であれば、XXXのオプションを追加するという考え方をやめてしまうのです。そして、そのパラダイムをXXXのオプションで○○○を実施するという方向にシフトします。

工場はいろいろな条件でモノを生産します。
条件が違うだけで、ベースになるものは同じです。つまり、生産物はシリーズであるわけです。であるならば、ベースになる部分をごく抽象的なインタフェースでルールのみを定義してやることにより、オプションで肉付けをすることが可能になります。
これがアブストラクト・ファクトリの基本的な考え方です。

2015年8月5日水曜日

実務に即したファクトリ実装

もし、○○○ならば、XXXをする。

これは極めてソフトウェア工学の中ではポピュラーなモノの考え方です。
常に通奏低音のように鳴り響き、まるで呪縛のように私たちを取り巻いている、ひとつの習慣として醸成されています。

今回はここを取り崩そうと考えています。

上の if文の中でさらに条件を想定して、もし、△△△ならば、□□□をする。というような構造を考えてみます。いわゆる入れ子構造です。

ここまでを整理します。
すると以下のような構造が見えてくると思います。

if ○○○ {
if △△△ {
□□□
}
else {
XXX
}
}
else {
// 何もしない。
}

ここでは、3つの処理系が存在することがわかります。
さらに、もし、△△△ならば…　という条件下でさらに入れ子になる構造…　と考えたところで、うんざりしますね。そしてバグの不安に駆られます。このような構造が（そう、構造そのものなのです！）ソースコードの平面的な世界観の中で表現された場合、人間の頭の中ではどのくらいの階層まで把握、管理ができるでしょうか？

いいえ、このような発想は、おそらくナンセンスなのでしょう。
もっと、シンプルに整理、管理できないのか？　ということに頭を使ったほうが、余程世のためなのだと思います。

皆さんであれば、どのような工夫をするでしょうか。

このように整理してみます。

if ○○○ {
if △△△ {
□□□　Aの処理系
}
else {
XXX　　Bの処理系
}
}
else {
// 何もしない。Cの処理系
}

この構造を階層で表現せずに、バラバラにしてまずはコンテキストで表します。
（表現が冗長になるのためコンストラクタの記述は割愛します）

まずは、AとBの処置系
class ABClass implements IFactory {
public void Execute() {
if △△△ {
// Aの処理をする。
}
else {
// Bの処理をする。
}
}
}

次にCの処理系
class CClass implements IFactory {
public void Execute() {
// Cの処理をする。
}
}

この段階でAとBの処理系をドライブする表現を記述します。

IFactory target = null;
if ○○○ {
target = new ABClass();
target.Execute():
}
else {
target = new CClass();
target.Execute():
}

if文の入れ子構造をひとつ減らすことができました。
ポイントは、もし、○○○ならば、XXXをする　という考え方から脱却して、XXXという条件で○○○をする　というように捉え直します。
いわゆるポリモフィズムの実務に即した応用です。

登録: 投稿 ( Atom )