火曜日, 3月 17日, 2015

FlatPressのレスポンシブ・ウェブ・デザイン化

FlatPress(1.0.2)でブログを立ち上げて、スマホでアクセスしたら、「あら、これレスポンシブじゃないのね。」と思ったのでした。字が小さい~。

レスポンシブ・ウェブ・デザイン(RWD)
パソコンはもちろん、スマートフォンやタブレットでも見やすく表示されるように、単一の画面で対応するデザイン

いまどき、レスポンシブでないのはいけてないと思いました。

FlatPressのWikiにResponsiveのテーマを2つみつけたのですが、ひとつは見た目が黒白反転で見難い、ひとつは動いてくれないので断念。

調べてみたら、あら、デフォルトのテーマのLeggeroが、最新のv2でレスポンシブですって!
ということで、ここからv2を落として、サイトを上かぶせで更新しました。
http://www.marcthibe … style-available.html

これでスマホからアクセスすると、字が自動的に大きくなります。

まだちょっと気に入らない点が。
左のメインのところに合わせて文字を大きくしていて、右スクロールがあるんですよね。
個人的には一列にしたいのです。出来れば、スマホ表示のときのみ。
テンプレートとスタイルシートの改修でなんとかなるかなぁ、と思いつつ、デザインの部分には疎いので、まぁぼちぼちやります。

ちょっコラ(ちょっとコラム)

上記で「上かぶせで更新」と書きましたが、事前にバックアップは万全にしましょう。
システムエンジニアの仕事では、「万が一に何かあった場合、すぐ前の状態に戻せる」を保証した作業が必須です。
「上書きしたので戻せません」は言い訳になりませんので、常に心がけましょう。

水曜日, 3月 11日, 2015

麻雀とシステムと想定外

私の持論は「よいシステムエンジニアは麻雀が強い」です。
優秀なエンジニアを見ると、その人が麻雀しない人でも「この人、麻雀したら強いだろうな」って思います。

麻雀というゲームを知らない方のために簡単に説明すると、麻雀は3種類の数牌が1~9まで4枚ずつ、東西南北(麻雀では東南西北)の風牌が4枚ずつ、白發中の三元牌が4枚ずつあって、手牌13枚に1枚引くもしくは相手が捨てた牌で、4つの順子(シュンツ、連番)か暗刻(アンコー、同じ牌×3)と対子(トイツ、同じ牌×2)の組み合わせを作れば和了(ホーラ、ロン、上がり)です。
その組み合わせの種類によって「役」というのがあって、強い役を作ると獲得する点数が多くなります。
ロンの前の状態が聴牌(テンパイ)、聴牌の前は一聴向(イーシャンテン)、その前が二聴向(リャンシャンテン)、三聴向、四聴向と続きます。

つまり麻雀とは

  • 聴向を進める
  • 役をより強い役に向かわせる

ゲームとなります。

「完成」に近づけ、「より強固なものを作る」のです。
ほら、システム開発に似ているでしょう?
(ちょっと強引ですか、そうですか)

まず麻雀が強い人は、牌を引いてきたときに「if」で考えていません。
必ず「case」の塊で考えています。
ケースで決まった行動をするから、迷うことなく即、打牌します。
そのケースをいかに多く用意できるか。
これで強さの大部分が決まります。

基本的な行動はテンプレートにして用意してあり、さらに現状を分析して細かくケースを組み立てます。
ケースを構成する要素は自分手牌の状態だけではありません。
河(ホー、自分や他者が捨てた牌)の状態、残り枚数、対戦相手の思考など、刻々と状況は変わります。

どのケースにも当てはまらない場合、引いてきた牌をそのまま河に捨てます。

ここで、先ほど「麻雀とは」で(ワザと)書いてこなかったゲームの要素が加わります。

  • 相手に振り込まない(相手に和了させない)
  • 回す、降りる(相手に和了させないために自分の手を進めるのをやめる)

自分がいくら聴向が進んでも、相手に上がられてしまったらしょうがないのです。
ときには降りることも必要です。
そこまで考えてケースを組みます。

緻密に組まれたケースには想定外はほとんどないのです。
それでも想定外は起きます。
だからゲームは面白い。
「常勝チャンプなんてありえない」と前田日明も言っていました。

ところがシステムはゲームではありません。
想定外は起きてはいけないのです。
それでも想定外は起きます。
最悪、システムを止める、ということになります。
想定外が起きたときに、被害を最小に抑える施策をし、なるべくシステムを止めないで対策出来るようにしなければなりません。

システムを止めても、被害が収まらない。
そんなシステムはこの世にあっちゃいけない、と思うのですよ。
システム屋としては。

土曜日, 3月 7日, 2015

HTML VALIDATOR

WEBデザインは専門外なのですが、長年WEB系のシステムに携わっているとブラウザ上のデザインも無視はできないのです。
インターネットが普及し始めたとき、技術本を片手にエディタでHTMLを手書きして「ようこそ私のホームページへ!」(笑)なんてやっていた時代に比べるとブラウザで出来ることは数倍に増え、同時にタグの記述も複雑になっています。
いまどき0から一つ一つ手でタグを書く人はいないでしょうけど、

  • アプリケーションが出力する動的部分
  • デザインがHTMLエディタで微妙に調整しきれない部分
  • HTMLエディタが出力する不要な部分(コメントなど)

を調整するのは、やっぱりまだ手作業で行うことになると思います。

昨今の複雑なタグの記述を調整するわけですから、やっぱり記述を削ってしまったり、タグを入れ子にしてしまったり、余計なものを増やしたり、いろいろしてしまうんですよね。
それでも何とか動いちゃうブラウザが多いもんだから、気づけず、エンドユーザが別のブラウザで表示してみたらちゃんと表示されなくてクレームになった、なんてこともありますね。

そこで今日ご紹介する商品は・・・(テレビショッピング風)
FireFoxアドインの「HTML VALIDATOR」です。
http://users.skynet. … la/new_install4.html

インストールとか細かいところは簡単ですので自分で調べてください。(不親切)
アルゴリズムが

  • HTML Tidy
  • SGML Parser
  • 併用

と三つありますが、SGML Parserをお勧めします。

FireFoxで対象のHTMLを表示して、ブックマークツールバーにあるHTML VALIDATORのアイコンをぽちっとするだけでHTMLコード上の問題を教えてくれます。
簡単ですね。

「ボクの書いたコードがエラーだらけで真っ赤だよ~」
と悲鳴が聞こえるかもしれません。
大丈夫です。これでひとつもエラーが出ないようなサイトは滅多にありません。
大事なのは「一つ一つのエラーに対し内容を吟味し、直すところは直す、無視するものは無視する」です。
もちろん、他のブラウザでの表示を意識した上で検討しましょう。

余談ですけど、私はとてもいじわるで、他人のWEBページ、特に企業のWEBページをみるとき、必ずページのHTMLソースをみます。
それで結構、人となり、企業のなりがみえるもんですよ?
嫌なやつですね。あなたのWEBページは大丈夫ですか?

火曜日, 3月 3日, 2015

ドキュメントを書きましょう

私が最初に入社した会社は親会社が策定したドキュメントフォーマットがきちんと整っていて、何をどこにどれだけのものを書けばよいか、規模によってどれを客先に納品するかなど決まっていました。
そんな会社で育ったせいか、ドキュメントというのはとても重要だと、その会社を辞めた後でも思っています。

それがいつからでしょう。
システムも「うまい、早い、安い」でないと仕事が取れなくなって、受注価格を下げるようになって、工数削減で何を犠牲にするかで「ドキュメント」をきっちり書かなくなることが多くなったように思います。

  1. 「どうせ詳細設計なんか書いても、お客さんが見てもわからないから」
  2. 「コード書いたほうが早い」
  3. 「工程が進むうちに設計書と実装がどんどんかけ離れていって、メンテナンスするのが困難だから」

そんな声をよく聞きます。

1.はそれでもよいと思います。
なぜなら、設計書は家を建てるところでいう所の「図面」だと思うのです。
図面はお客さんよりもそれを見て大工さんが作れなければ意味がないです。
図面を引かない家に住みたいですか?そういう話だと思います。

2.はわかるような気がします。
決定した仕様を技術者の言葉に翻訳するのが設計書、コンピュータの言葉に翻訳するのがコード。
同じことを、二つの言葉に、しかも同期をとって翻訳しなければならないのです。
面倒ですね。コードだけなら一つでいいですね。
でも、例えば「このアプリケーションはどんな処理をやっているのか」の概要を知るために「コードを見てください」ってのはどうでしょう。
それが納品した客先だったり、保守運用の会社だったりすると「コードを見ろ」はお粗末ですね。
そこで「そこそこの設計書」をどこでも書くと思います。

でもそれが3.の「設計書と実装の乖離」につながり、同期をとろうと思えば「メンテナンスする」というコスト高の原因になってくるのだと思います。

さて、ここまで問題は出しても解決策を書いてきませんでした。
というか、自分が言いたい解決策は表題通り「ドキュメントは書きましょう」ということなんですけどね。
そこはコストとして削れるところではない、と主張したいわけです。

もう一度書きます。
「図面を引かない家に、あなたは住みたいですか?」

ドキュメントのメンテナンスを効率よくするための解決策、一緒に考えましょう。
DOAとか、なんとか、かんとか。

日曜日, 3月 1日, 2015

このブログのシステム構築(後編) - 設定もうちょっと

さて、FlatPress、記事を書いたり出来るようになったでしょうか。
この手のシステムは、まぁ、壊れない程度にいろいろやってみて覚えるのがいいです。
ただし、くれぐれも言いますが、他のユーザやサービスに影響が無い程度にしましょうね。

前回までで、セットアップが完了し、記事が投稿できるようになったはずです。
ここでもうひとつ、やっておきたいことがあります。
システムセキュリティに関わる、重要なことです。
いくつかFlatPressの導入に関わるサイトをみてきましたが、インストール、設定、記事を書く、ぐらいまでで、ここまで書いてある記事は少ないようです。
2015/03/21 追記
こちらのサイトが日本語サイトで情報豊富です。美人時計つけるかなー(笑)
http://flatpress.info/

セットアップページを潰す

インストール後、
http://<myserver-url>/flatpress
にWEBブラウザからアクセスしてセットアップを行ったと思います。

そのときのコンテンツが、実はまだサーバ上にあるのです。
http://<server-url>/flatpress/setup.php
をWEBブラウザからアクセスしてみましょう。
fp-setup.jpg
こんな画面が出てきます。
そこには、こんな文言が。

Remember! It’s not safe keeping setup.php and the setup/ directory on your server, we suggest you to delete it!

「setup.phpとsetupディレクトリを削除することを提案します。」
サーバに上のsetup.phpとsetupディレクトリは削除してしまいましょう。

ついでに、

  • docs ディレクトリ
  • CHANGELOG
  • COPYING
  • LICENSE
  • README
  • README.md
  • TESTING

この辺のドキュメント系は削除してしまいましょう。

パスが/flatpressじゃ味気ない

あれ?このブログのパス /flatpress じゃないぞ!
はい。いったん/flatpressに構築して、自分のディレクトリに移動しました。
サーバ上、物理的にディレクトリ名を変えて、管理パネルの設定からパスを
http://www.mucom.net/yasu3156
に変えるだけで動作しています。
パスは/flatpressでなくても問題ないようです。

この先の課題

とりあえず、テーマを変えたりしてみたいと思っています。
FlatPressはWordPressのクローンらしいので、WordPressのテーマやプラグインが使えるとの情報を得ています。やってみたら、ここに書くようにしますね。(2015/03/21 削除 テーマはそのままでは使えませんでした。もうちょっと研究してみます)
それと、ちょっと気に入らないところもあるので、カスタマイズで回避できたらいいなぁ、と思っていますが、それもやってみて、上手くいったら書いていきます。

ちょっコラ(ちょっとコラム)

「セキュリティに関わる重要なこと」と大風呂敷広げてファイルの削除を今回は紹介しましたが、意外とこういう「不要なファイルや設定画面へのアクセスをなくす」作業をやっていないWEBサーバはあります。
酷いところだとApacheのインストール成功のページが表示できたり、管理画面のログイン口が出たりしますね。
外から侵入される可能性があるサーバでお試しの場合でも、そういうところは必ず塞ぐようにしましょう。
セキュリティ診断会社からWEBウェブサイトのセキュリティ診断を受けると、重大な項目として指摘される事項になります。