スモールビジネスのIT日誌

• (2013-05-18 05:41:00)

ブログはドメイン運用の変更に応じて引っ越し需要は多々あり。ブログに限らず、システムは引っ越しを想定して運用を開始する(2013/05/17)

システムの引越はたんにコスト

引越は労力と体力を消耗するに割に引越したところで、何か価値を作り出すわけでない。なるべくしなくてよいような設計やプランを心がける。とはいえ、環境の変化などもあり、引っ越さざるを得ない状況は必ず起きる。

時代とともに変化するドメイン運用の内容

現在は以前ほど意味がないが、以前、SEO的な効果を狙って企業のサイトではオフィシャルサイトとサテライトを分けて相互リンクする手法が広く採用されていた。

またどんな企業でもビジネスプランは常に変化しているので、SEO対策とは別にドメイン運用の内容も常に変化している。

シンプルなシステムならファイルコピーだけの話

ドメイン名は好き勝手に取得・廃棄が可能。コンテンツもファイルのコピー(ダウンロード・アップロード)だけなのでこちらも制限はない。

Wordpressなどデータベース付きのCMSの場合、DBの引っ越しがあるが自社運用である限り、基本的にいろいろ柔軟性がある。

要はシンプルなシステムなら引っ越しは簡単。逆にカートなどDBやシステムをバックエンドに据えたサイトなら、システム部分を個別サイトに独立させておくことで、コンテンツ自体の引っ越しは気楽になる。

ロリポブログの注意点は画像ファイル

ロリポブログにはお世話になっている。こちらの引っ越しはxmlファイルのエクスポート・インポート機能が付属するので、数百程度の記事なら問題なく移行可能(記事数が多くなると調子が悪い場合があるようだ)。

問題は画像ファイルのダウンロードができない点。よって画像ファイルは別の自社サーバーなどで管理しておくと移行の際、問題は少ない。

ロリポブログの開設＆引っ越し方法

(1)レンタルサーバ付属のロリポブログには自社ドメイン名のサブドメインとして命名できるが、基本はjugemドメインの「○○.jugem.jp」名。

ドメイン名を廃棄した場合でも、独立したjugemブログへの移行も可能。よって、ブログの命名は「○○.jugem.jp」を基本に考える。また「○○.jugem.jp」の「○○」は覚えやすいように自社ドメイン名のサブドメイン名と同じにしておく。

(2)記事の書き方
　・画像ファイルは別の自社サーバーにアップする
　・引っ越し後、新しい投稿日時(タイムスタンプ)の影響を受けないよう、投稿日時はシステムの自動記帳に頼らず、手書きで行う

(2)「○○.jugem.jp」を廃棄・移行
　・カスタマイズしたテンプレートのhtml/cssファイルをコピー
　・ブログ名や説明情報などをコピー

　・[削除] 全記事
　・[削除] ブログタイトルと説明
　・[削除] ユーザー情報・ユーザープロフィール

　・htmlのコードに下記のリダイレクトコードを書き加える
　＜meta http-equiv="refresh" content="0;URL=http://新サイトURL/"＞

• (2013-05-12 11:38:42)

Twitterはいつの日からかGoogleの検索結果に反映されなくなり、過去の投稿は多くの人にとって、どちらかと言えば、不都合な状況になりつつ・・・(2013/05/12 小平探検隊)

データ保存はTwitterにて提供されていた

全ツイートの保存ツールと一括削除してくれるツールを探す。保存ツールはTwitterにて提供されていた(最近、提供がはじまったらしい)：

「設定」 → 「全ツイート履歴」で保存可能。

準備ができるとメールでダウンロードサイトのURLが送られてくる。ダウンロードするとcsvファイルがあるが、文字コードがUTF-8なので、Excel2003などでは開くことがができなかった。UTF対応エディターなら開ける。

サポート終了が多いのか、Twitter周辺ツール

データ保存ツールに関しては検索するといろいろでてくる。とくに露出が多かったMK Twitterは本日の時点で動作せず。複雑なアプリでないので、自分の操作ミスとは思えない。

他に削除してくれるサービスやツールがあるが、だいたい動作しなかった。

おそらく、TwitterのAPIが変わったのだろう。こまめにメンテしていないとこういうツールやサービスはすぐに動作しなくなる。そして、Twitterにはもはや動かないツールやサービスが多いような印象を受けた。

Twitterは水物？

作業を通してTwitterは水物というコトバが脳裏をかすめた。結局、tweeteraser.com というサービスで消していったが、ブラウザによって挙動に差がある。IEは動作せずハングアップする。

Chromeは多少安定して動作したが、いずれにして、一括動作は成功せず、少しずつ手作業で消していくしかなかった。動作は不安定だ。しかし、Twitter本体で削除するより遙かに楽だった。

Twitterの今後

Twitterはどういうメディアになっていくのだろう？

先日のボストンマラソン爆破事件ではマスコミを凌駕するリアルタイム性・情報量・精度を誇りプレゼンスを示した。マスコミの情報源としての存在意義を感じる。マスコミにとっては各ツイートの真偽は今後さらに悩ましくなるだろうが宝もある。

一般人にとっては特定のインタレスト・グループで情報源になるのか。

企業にとっては？・・・昔からTwitterの付き合い方がわからなかったが、やはり今でもわかならい。インフラとしてのプレゼンスを考えると、関わらないというわけにもいかない、が企業関係者のホンネか。

• (2013-05-08 15:13:33)

一括トリミングは一括リサイズほど使わないが、今回数十枚の商品写真で周囲の不要部分を一括でトリミングしてくれるソフトを探した。

商品写真など定型写真で効果大

同じ背景で、似たようなサイズの商品の写真を多数撮影する機会はネットショップ運営者にはたまにある。

素人には厳しい商品写真はプロにお任せした方が有利だが、クオリティを要求されないものは自分で撮影・編集ということもある。

単機能が嬉しい

一括トリミングについて検索すると、IrfanViewが使えるとあった。

しかし、こういう画像関連ソフトは「何でもできる総合ソフト」より、それぞれの機能を切り出して、単機能化して「速く・軽く」できるソフトが自分には向いている。

PhotoShifter

Vectorでは「トリミング、リサイズなどの加工が行える画像ビューア/画像一括変換ツール」というサブタイトルになっている。

一括トリミングだけでなく、リサイズや画像フォーマット(jpg/gif/png/tiff)などの変換やってくれる。

もう1種類違うフリーソフトを試したが、こちらが機能が多くわかりやすかった。

PhotoShifter、一括トリミング操作方法

設定 → 変換設定 → トリミングを有効にする → 幅指定

「幅指定」は四方(左右上下)から何ピクセルを削除するかを決定する。

• (2013-04-03 10:11:07)

Flickrのようなサイトを自分で作りたいとき

探してみたらGalleyというフリーソフトがあった。gallery-3.0.2.zipをダウンロードして、インストールしてみた。凄い、これがフリーってのもインターネットの世界には様々なボランティアが存在するといつも驚かされる。できること

・画像の投稿

・コメントの添付

・サムネイル生成表示

・画像のポップアップ表示

・訪問者やユーザーからのコメント受付

などなど

しかし、さすがにFlickrの方が高機能であり、集客力もあるので、自社やプライベートで運営する特別な目的がない限り、外部の汎用的なサービスを利用した方がよいかも。動画ならYouTubeに上げることと似ている。今日の評価は終わり。

• (2013-03-31 09:25:13)

正直、ターゲットにされたら守りようがないと思えてくるネット犯罪。実際の事件から教訓を学ぶ(2013/03/31 小平探検隊)

カード情報流失事件の概要

「購入画面内の『支払方法選択画面』に入力されたユーザーのクレジットカード情報が、第三者の外部データベースサーバに送信される内容の改ざん」が発生し、1万人以上のクレジットカード情報が流失。

クレジットカード情報とは「カード番号、カード名義、セキュリティコード、有効期限」。

・カード情報流失件数：12,036件
・期間：2013年02月06日-03月14日(47日)　(事件発生日の2月6の特定方法は不明)

不正アクセスが発覚したのは3月14日午後11時とのこと。マスコミ発表は3月15日。このタイミングが、株価とどのように連動するかも教訓。

誤解を招かないマスコミ発表が必要

カード情報のうち、1回与信するごとに破棄が義務づけられているセキュリティコードを、JINSが社内保管していたとして、怒りの声を上げている掲示板があった。

JINSは保管していないとしているが、「保管していた」という悪事情報が瞬時に拡散し永久に残る点は非常に厳しい。

どのように発表すれば、ネットユーザーの誤解を誘発せず風評被害を最小限に押さえられるかは広報担当者には身に迫る思いだ。マスコミ発表時には注意を要する。

セキュリティコードはあまり役立たないかも

セキュリティコードは架空カードの不正使用対策として近年ようやく普及した印象があるが、あまり役立たないことが判明した。

ショップサイドのデータベースに記録がないので、万一データベースがクラッキングされても、セキュリティコードは安全という発想だが、支払画面から直接奪取されたらセキュリティコードも意味がない。

支払画面改ざんは想定外だったか？

ニュースを読む限り、今回の攻撃はデータベースがクラッキングされたわけでなく、WebサーバもしくはFtpサーバがクラッキングされたことになる。

Webページの書き換えや改ざんはお決まりのサイバー攻撃であり、実際に事件は多発している。カード番号入力するような非常に注意を要するページにはそれなりの対策が施されるべきという教訓を感じる。

なぜこういう攻撃が事前に想定されていなかったのか、反省すべき点で、今回の事件がケーススタディとなって、カード決済画面の改ざん防止対策が進むように思う。

たとえば、こういうセンシティブなページはソースをオリジナルソースと定期的にコンペアするようなプログラムを流しておくくらいならコストもかからずよいかもしれない。

どこの会社のサーバがクラックされたのか？

被害元のJINSではクレジットカード情報は一切保管しいないとのことなので、どこかの決済サービス会社の画面と推測される。どこの決済代行会社が被害にあったのか気になっている。

普通に考えれば、凄いトランザクションや事情でもない限り、セキュリティ上、決済サーバを自社に設置する企業は多くない。

一般的な企業なら、顧客のカード情報は見ることも保管することもしたくないはず。それよりもカード決済専門のサービス会社に委託したい。

そうするとそういうサードパーティでは一社専用ではなく、いろいろな企業の決済サービスを請け負うので、クラッキングされたのはJINSだけでなく多数の企業で被害が拡大するように思うが、そういう報道はなく、決済サービス会社の名前も出てこない。

私が調べた範囲ではJINSのシステム開発会社さん名は見つかり、その魚拓も保管されていた(ただし、現在は削除されている)。

JINSでは調査結果を4月中に発表するとしているので、何か具体的な情報がでてくることを期待している(※後日談:結果的に、技術的にどういう操作が行われたのかなどの具体的な情報は表に出ることはなかった)。

ところで株価の動き

JINSの株価はこの事件でほとんど影響を受けなかった。カード情報流失は日常化しており人々が慣れているのかもしれない。

もう一つ、JINSサイトを構築したシステム開発会社さんの株価は事件の公表が3月15なのに3月11日くらいからボリュームを伴った激しい値動き。偶然なのか、パワーゲームなのか。