日曜日, 11月 15日, 2015

スパムコメントとの戦い(1/2)

本業が忙しく、なかなかネタがアップできず、気が付けば8カ月もブログ放置していました。
本業の忙しさは相変わらずでなかなかネタが見つからないのですが、この放置の間にネタが転がっていました。
このブログのコメント欄に膨大なスパムコメントがついていたのです。
一日10件以上のコメントが付いて、総数300以上でした。
これはなんとかしなけりゃいけない。

コメントを一気に消す

コメントを選択して消すなんて面倒くさくてやっていられません。
直接コメントファイルの削除をしました。
FlatPressインストール先のfp-contentの下に西暦の下2桁のディレクトリ、その下に月2桁のディレクトリ、その下にエントリごとのディレクトリがあります。
エントリごとのディレクトリの下の「comments」ディレクトリは以下のファイルを削除すれば、コメントはきれいに消えてくれます。

スパム対策

対策としていくつか方法を考えました。

  1. パスワード・画像認証を導入する
  2. コメントを承認で公開するようにする
  3. IPアクセス制限

Flatpressのプラグインで画像認証導入は特殊なプラグインを入れることもなくできるようなのですが、アクセシビリティの低下が個人的に好きではないので見送りすることにしました。
まずは「コメントをブログ管理者が承認しない限り公開しない」を導入してみます。
「投稿しても表示されないなら、いつかあきらめて消えるだろう」という考えです。
導入したプラグインは
Comment Center v1.1
http://www.pierovdfn.it/2011/06/30/plugin-comment-center-v11-flatpress/
です。(確認するとv1.1.1があるようですが、それはまだ試していません)
残念ながら日本語化はされていません。

ダウンロードしてFlatpressインストール先のfp-pluginsディレクトリに展開します。

FlatPressの管理用ページから「プラグイン」を開きます。
「プラグイン」列にプラグインの名前がアルファベット順に並んでいますので、「Flat Press Comment Center」の「切り替え設定」列の「有効にする」リンクを押します。
他のアンチスパムの併用もできるようですが、私のところはこのComment Centerの承認機能のみ有効にしたいため、「Accessive Antispam」と「Akismet」は「無効」にしました。
「QuickSpamFilter」(いわゆる「NGワード」を登録し、含まれる場合は投稿させない機能のようです)は有効のままですが、設定していないので機能しません。

FlatPressの管理用ページから「ブログ記事」→「Comment Center」を開きます。
「Add a new pollicy」のラジオボタンを選択し、「Apply to」を「All Entries」のラジオボタンを選択し、「Behavior」を「Comments need to be approved」を設定し、「Save Policy」ボタンを押します。
これでコメントは管理者が承認するまで公開されることはありません。
fp20151115_1.PNG

Comment Center導入による効果

結論から言うと、あまり効果がありません。
すぐにコメントが反映されないので、ブログの見た目上キレイになるのですが、やはり相手は自動投稿ロボットのようでお構いなしに投稿してきます。
こまめに管理用ページの「Comment Center」から未承認のコメントを削除すればよいのですが、面倒です。

次回はもっと根本的な対策をしてみます。
(次回に続く)

火曜日, 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とか、なんとか、かんとか。