OSX専用の開発環境/エディターであるEspressバージョン2のα版が公開されてます。

http://macrabbit.com/espresso/2/

Permalink | Leave a comment  »

記者「ところでパスワードの保存はどうすればいいんでしょうね」

デスク「決まってるだろ、小沢だよ小沢」

記者「さすがデスク、情報通ですね」

デスク「いいから検索しろ！」

すみません、出だしから少し間違えました。

パスワードの保存は次3つののルールにのっとってやりましょう

ルール1

パスワードは平文で保存しないで暗号化する

ルール2

復号化できる暗号化をしない。

ルール3

パスワードは暗号化する

具体的にはこんな手順で

１.パスワードを暗号化するためランダムデータ(Saltとかいう奴)を用意します。

2.Saltを使って暗号化

3.保存

ユーザーがパスワードを入力したら

1.入力したパスワードを上と同じ手順で暗号化

２.データベースのパスワード(暗号化済み)と比較

以上

ちなみに、Saltはユーザーごとに用意する必要があるので、「パスワードを忘れたときのヒント」みたいな感じでユーザーに入力させる方法もとれます。

その場合はSalt自体も暗号化する必要があるから、Saltを暗号化するSaltもほしくなっちゃう。

塩分とり過ぎ。

なんつって。

結論

システム開発を依頼してて、相手が「ユーザーがパスワードを忘れたときはメールでパスワードを送ります」とか言い出したら、危険信号。

Permalink | Leave a comment  »

ウェブから流出して困る個人情報の最右翼はもちろん｢カード番号｣ですが、それ以外の個人情報はどうでしょうか？

電話番号とかは嫌ですね。住所とかも。

でも、実際のところ、ウェブサイトで収集しなければならない個人情報は

・問い合わせなどのユーザーからのアクションが可能なら「メールアドレス」

・ログインするサービスなら「パスワード」

・課金するなら「決済の時に必要な情報」　:カード番号、有効期限、カード名義、セキュリティーコード

くらいのはずです。

課金に必要な情報は決済サービス業者に管理を任せるとすると、一般的にウェブサイトで収集「しなければならない」情報は「メールアドレス」「パスワード」くらいになります。

(逆にいえば、今多くのウェブサイトで収集している個人情報は、「本来そのサービスを提供するうえで不要なのにサイト運営側の都合だけで収集している」といえます。)

メールアドレス

ログインする必要がないサービスであれば、最悪流出するのは「メールアドレス」だけです。

想定できる被害は迷惑メールが増える、とかでしょうか？

でも、それって○天とかに登録しても同じことが起きたりしますね。

それはともかく、ウェブサービスを考えるなら、「どうすればログインしないですむか？」ってことを真剣に考えるべきですね。

ログインしなくても、ある程度のセキュリティーを担保することは可能なはずです。

パスワード

どうしてもログインしてもらわなければならない、となったら「パスワード」の登場です。

そして、ここがウェブサービスを考える上で一番の山場です。

個人情報が流出するとき、パスワードがそのまま、つまり平文のまま流出することが結構あります。ヘブンじゃなくてね……

開発する側からすると、パスワードが平文で保存されてるって、ちょっとあり得ない話です。

データベースにパスワードが暗号化されないで保存されているということは、こういうメリットがあります。

・ユーザーがパスワードを忘れたときに、メールで送ってあげることができる

逆に

・ハッカーに侵入されたときに、パスワードをそのまま見られちゃう

という心配もあるわけで、そんなのちっともメリットじゃない。

パスワードを忘れたらパスワードを再発行するためのワンタイムURL(期限付きの一意のURL)を送ってあげればいいだけです。

ところで、なんでパスワードが他人に知られると困るかというと

・多くの人が複数のウェブサービスで、同じパスワードを使っている

からなんです。

つまり、流出したサイトだけの問題ではなくなっちゃうのです。

・gmailのパスワードを勝手に変えられて

・Amazonの住所とメールアドレスを変えられて、知らないうちにいろいろ購入されて

・楽天でいろいろ購入されて

・Google Analyticsでアクセス数をリセットされて

・facebookのプロフィール写真をアニメ画像にかえられて

もうしらんがな。

Permalink | Leave a comment  »

パスワードが平文とか……

マジなんですかね。

もういっそのこと、個人情報はできるだけ収集しない方向でいったほうが、ウェブサイトはいいんじゃないでしょうか。

マーケティングにはメールアドレスさえ分かれば十分だと思いますよ。いやほんと。

などと言いつつ、個人情報の流出というのはひと事ではないわけで、ソニーを批判する勇気などまったくなく、明日は我が身かなどと、いつも思いながら開発するわけで、母さん、東京は星が見えません。

「ひと事ではない」とか言いつつも、結局今のところひと事なので、流出したパスワードの分析とか見ておもしろがったりするわけで、母さん、もうちょっとしつこいですか。

http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html

これを見るとパスワードというのは、だいたい

・6〜8文字

・英数字だけ

らしいですな。

もうパスワードって仕組みもなんとかならないかな。

Permalink | Leave a comment  »

配布されている公式のパッケージをそのままインストールするとエラーが発生します。

現象としては、いくらがんばってもMySQL君が起動してくれない、そんな感じです。

原因はmy.cnfのオプション設定がよろしくないようで、エラーが出ている箇所をコメントアウトしたら動き出しました。

Permalink | Leave a comment  »

CodaとかEspressoとかね。OSX専用ですが。

うちは数年使っていたBBEditからCodaに乗り換えました。

BBEditは、phpのプログラミングにはいいけどHTMLとかCSSになるとちょっと弱々しい感じ。

デザインも古くさいし。

CodaはTransmitとかSubversionと連携できるのでいいと思います。

まさか、いまだにWindowsでFTPとかしてないですよね？

Permalink | Leave a comment  »

いま仕事が忙しいので手短に書いときますが、

1.　自社サイトのコンテンツをCMSとかで動的に生成。このときfacebook表示用に調整しとく。

2.　1のページをfacebookのアプリとして登録

3.　公式ページにアプリ登録。なんなら最初に表示するページとして、そのアプリページを設定しとく。

これだけで大丈夫

たぶん。。。

たぶんっていうのは、ほら、facebookとかgoogleとか平気で仕様変更するから。じゃんじゃんするから。

仕様変更の2ヶ月前くらいに電話してきて

「あのぉ、フェイスブックだけど」

「なに、ひさしぶりじゃん」

「言いにくいんだけどさ、こんど仕様変更するから」

「え！」

「ごめん」

「え〜」

「ほんとごめん」

「このあいだ変えたばっかりじゃん」

「しょっちゅうアップデートしないと、いつ飽きられちゃうかって心配でさ。こっちだっていろいろ大変なんだよ！このあとも200件くらい電話しなくちゃならないし。じゃあね」（ガチャン）

「フェイスブックぅ〜」（ツーツーツー）

みたいな会話があるならいいんだけど。

Permalink | Leave a comment  »

例えば、あなたがfacebookに新規登録して、勤務先を入力したとします。

するとどうでしょう！

まだ、その勤務先のページができていないときは、勝手に「コミュニティページ」なるものが作成されてしまいます。

最初は、別に問題ないような気がします。

でも、あなたの会社の上司が「うちの会社も、facebookに公式ページとかを作るべか」なんて言い出すとめんどくさいことになります。

だってね、もうこの時点であの勝手に作られちゃった「コミュニティページ」のほうで「いいね」ボタンを押した人が5人くらいいるからです。

かくして、公式ページを作成しても、コミュニティページはそのまま生き残り、せっかく「いいね」を押してくれても２つのページで分散してしまうことになります。

例えば「IBM」のページを見るとわかりますが、公式ページのほうは約5万人以上が「いいね」と言っていて、コミュニティページのほうは5千人以上のひとが「いいね」と言っています。なんだかもったいないですね。英語で言うと「Mottainai !!」ですね！

でも、ご安心を、どうやらコミュニティページと公式ページは統合ができるらしいですよ。

たとえば、ここを見て下さい。

http://www.facebook.com/help/new/?page=1155&hloc=ja_JP

「統合できます」って言ってますね。

「統合する」ボタンを押せばいいんだ！

簡単ですね。

あとは、そのボタンがどこにあるかわかれば完璧です……

どこだろう……

なんか、facebookってこんなのばっかりですな。

驚くほどわかりにくい。

Permalink | Leave a comment  »

軽くて安心して使えてJQueryなリッチテキストエディターelRTE。

バグがありました……

どんなバグかというと、XHTMLで「area」タグを使うと、エンドタグの「/>」が「>」に勝手に変えられちゃうってこと。

修正は簡単で、elrte.full.jsなら3041行目あたり

xhtmlTags : function(html) {

    return this.xhtml ? html.replace(/<(img|hr|br|embed|param|link)([^>]*\/*)>/gi, "<$1$2 />") : html; 

}

を

xhtmlTags : function(html) {

    return this.xhtml ? html.replace(/<(area|img|hr|br|embed|param|link)([^>]*\/*)>/gi, "<$1$2 />") : html; 

}

に変えるだけ。

ほかのタグも必要なら同様に追加すれば大丈夫です。

Permalink | Leave a comment  »

CMSの編集画面には、だいたいリッチテキストエディターがついてますね。

「ワープロ感覚で使えますよ」ってやつ。

代表的なのは次の２つでしょうか。

1.　TinyMCE

2.　FCKEditor改め CKEditor

区別がつかない？

はい、その通り。機能も大差ありません。

多くのCMSに搭載されているのは、この２つのうちのどちらかと言っても過言ではありません。

でも、どちらもフル機能を無料で商用で使おうとするとちょっと無理があります。

そこで、いま弊社のCMSでは違うヤツを使ってます。

それがこれ

3.　elRTE

JQuery UIを使っているので、見た目のカスタマイズは簡単そうです。

ライセンスは「三条項BSDライセンス」。

使っていて、上のふたつより軽い印象です。

Permalink | Leave a comment  »

いまこの時点で、日本全国に２人くらいはいるでしょうか？悩んでる人。

この記事はあなたのための記事です。

ページ内のリンクをクリックしたとき、JQueryのscrollでスルスルってスムーズにページ内を移動させるやつありますね。

Jqueryのプラグインでも沢山ありますし、こんなコードを使ってもいけますし。

$('a[href*=#]').click(function() {
                if (location.pathname.replace(/^€\//,'') == this.pathname.replace(/^€\//,'') &&　location.hostname == this.hostname) {
                        var target = $(this.hash);
                        target = target.length && target;
                        if (target.length) {
                                var sclpos = 30;
                                var scldurat = 600;
                                var targetOffset = target.offset().top - sclpos;
                                $('html,body').animate({scrollTop: targetOffset}, {duration: scldurat, easing: 'easeOutExpo'});
                                return false;
                        }
                }
        });

ところがこのコード、SafariとかのWebkit系のブラウザでうまく動作しないことがあります。

原因は、JavaScriptではなくスタイルシートのこれ！

html, body{

overflow:hidden;

}

overflow:auto でもダメっぽい。

Permalink | Leave a comment  »

ウェブからPosterousに投稿するときの話です。

画像を表示させるには、

• 別のサイトの画像へのリンクを設定する
• 画像をアップロードする

この２通りあります。

別のサイトの画像を直接表示させるというのは、いつリンク切れを起こすかわからないので不安で仕方ありませんね。

ということでアップロードしたくなると思うのですが、

このボタンをクリックして複数の画像をアップロードすると、なぜかギャラリー表示になってしまいます。

これをひとつずつの画像に分割するには、

• そのギャラリーをクリックします。
• ギャラリー編集画面が出てくるので、そこで「Expand to different galleries」をクリック。これでバラバラの画像になります。
• ちなみに、このギャラリー以外に画像があると「Combine width other galleries」とかでて、ほかの画像とギャラリーを合体させることしかできません。

Permalink | Leave a comment  »

ToDo管理してますか？

水族館勤務じゃないから関係ない？

え、トド？

はいはい、そういうノリはいりませんよ。

仕事で使えるToDo管理ツールを探して幾歳月、いろんなツールを使ってきました。

その中でも、iPhone単独ではなく、ウェブサービスやデスクトップアプリケーションと連動できるツールをご紹介します。
※ほかにもいっぱい試したんですよ。でも仕事にはちょっと、というのがばかりでした。

1.　Things

シンプルなデザインとシンプルな機能が売り

Mac用デスクトップアプリケーションと連動

シンプルさを物足りなく感じるか、美しいと感じかがポイント。
個人的には、GTDに忠実であろうとするあまり、なんだか使いにくくなっていると思います。たとえば、期日があるToDoはToDoではなくアポイントメントである、そういうのはスケジュール管理ソフトでやってくださいとか言っちゃうGTD原理主義的な姿勢とか。約束した機能が何年経っても実装されない、バグの修正に長期間かかる、といった開発体制。きっと和気あいあい楽しくやってるだろうな。サーフィンの合間に仕事したりして。想像ですけど。
このまま使ってて大丈夫かな。そう思わせてくれるアプリ。

2.　Appigo Todo

必要な機能を揃えた味気ないヤツ

Toodledo.comや独自有料サービスと連動

使いやすい。それだけは間違いがありません。
しかし、セクシーさが足りません。こういうツールにセクシーさを求めるのがいいのかどうかわかりませんが。
個人で使うには、これが一番かも知れません。

3.　Toodledo

4.　Taska

なかなか良かったのにね

Toodledo.comと連動

最初はとても良くできたアプリでした。個人で開発しているためでしょうか、機能追加するたびにバグが増える感じになってしまいました。去年の夏頃からは事実上、開発停止状態にあります。現状で満足できるなら使ってみるといいと思います。でも長い目でみると使わないほうが良いでしょう。

5.　OmniFocus

GTD戦士の必需品

Mac用デスクトップアプリケーションと連動

よくできてるんですよ。たぶん。でも長く使い続けているとちょっとした使い勝手や表示の癖が苦痛に感じようになってしまいました。なんか肌に合わないというか。GTDを厳密に運用したい人にはいいかもしれませんが、気軽に使うにはMac用デスクトップアプリケーションとあわせて一万円以上する価格設定ではちょっと手が出せないでしょう。
高価格にわりにはタスクを別の人と共有するようなコラボレーション機能が無いのが残念です。

6.　Flow

これからの活躍に期待します

有料ウェブサービスと連動

奇麗なデザインによくまとまった機能。有望だと思います。コラボ機能があるのでいいと思います！ただし、プロジェクトの考え方がちょっと違うように思います。プロジェクトはフォルダとは、目的と期限を持っていることが異なります。個人的には、プロジェクトの情報として期限やメモなどができないのが重大な欠陥でした。あと、有料のウェブサービスが必須ですのでご注意ください。
個人で使うにはAppigo Todoかこれか、どっちかにするとよいでしょう。もしチームで使うなら、このアプリを試してみてもいいと思います。デザインはNozbeなんかよりも全然良くできています。

7.　Nozbe

チームで使うならこれ

有料ウェブサービスと連動

チームでタスク管理するなら、事実上、これ以外の選択肢はありません。
弊社でも使っております。「ノズビー」と呼ぶらしいのですが、弊社ではあくまで「ノズベ」と野暮ったい感じで呼んでます。なぜなら、デザインが野暮ったいから。
機能は豊富で、ほかのToDo管理ツールが持っている機能はほぼ備えていると思っていいです。その上、EvernoteやDropBoxと連動できたりもします。
難点を言うなら、デザインのダサさ（トップ画面にでかいロゴとかいらないし）と、プロジェクトが多くなったときの管理のしにくさ、でしょうか

ということで、個人で使うならいろいろあるから気に入ったのを使って下さい。

チームで使うときは、FlowかNozbeになると思います。

どちらもウェブサービスのトライアルができるはずですので、お試しください。

Permalink | Leave a comment  »

つづきです。

ほかにもパイプを作ってくれた人がいます

http://pipes.yahoo.com/pipes/pipe.info?_id=7084463c441f291a79e91c9c0c39b9c3

あとは自分で作ってみるとか。

http://pipes.yahoo.com/pipes/

facebookのノートへのインポートでエラーが出るときは、こちらも試してみてください。

場合によってはRSSインポート用のアプリを使うしかないかも…

（この件、ひきつづき調査中です）

それと、posterousで記事を編集したら「publish」じゃなくて「save」を押さないと、同じ記事が何度も投稿されちゃうのね。

Permalink | Leave a comment  »

別にfacebookに限らないのですが、アメブロのRSSを別のウェブサービスで表示しようとすると、そのRSS中に勝手に広告が仕込まれて嫌んなっちゃう、という話。

広告の無い無料のブログサービスが大量にある現在、こんなやり方は逆効果でしょうに。

大人の事情があるんでしょうか……

これを消すには、ちょっと面倒なことをしなければなりません。

以下のYahoo Pipesにアクセス

http://pipes.yahoo.com/pipes/pipe.info?_id=DrFZRK663RGaE1sE1pzWFw

「URL」にfaebookとかに登録したアメブロのRSS URLを入れて「Run Pipe」して「Get as RSS」

アドレスバーにあるURLが新しいURLです。

このURLをまたfacebookに登録してあるアメブロRSSのURLと入れ替えればオッケー。

のはず、これから弊社代表が実際に試してみるそうです。

（なぜか、エラーが起きました……）

Permalink | Leave a comment  »

フォームに入力した郵便番号を住所に変換する処理は、どこの企業のフォームでも実装していると思います。

ただ、この変換の元になる郵便番号データは日本郵便から直接取り込んでいるわけではなく、日本郵便が提供しているCSVデータを変換して使用しているのが通常のようです。

なぜなら、日本郵便が公式サービスを提供していないから。する気配も無いから。無いから。

そこで、問題なのが、データを常に更新しなければならないってこと。

郵便番号って結構変わってるんですよね。

AjaxZip3は（その名の通りなんですが）AjaxZip2をアップグレードして自サーバーに郵便番号データを保存しなくてもいいよ、ぼくたちがデータ更新を代わりにやるから（たぶん）。というボランティア精神溢れる（たぶん）JS。

http://code.google.com/p/ajaxzip3/

でもやっぱり、こういうのってサードパーティーに任せないで、郵便番号を管理してる日本郵便がちゃんとやるべきですよ。

Permalink | Leave a comment  »

「鍋焼きうどん始めました」的な。

いやむしろ季節的には「かき氷始めました」的な。

どっちでもよろしい。

弊社社長から「書け書け」と言われ続けていた技術系ブログ。

Posterousの使い勝手を確かめる意味でもいよいよ初めてみるわけです。

そう、まるで老子が隠棲する間際に弟子に捕まって書かされた「老子道徳経」の逸話にも似た、

いやそれほど似てない、

むしろ、スリで捕まった老人が書く獄中記のような心持ち。

そんな大げさな中にも知性を感じさせる静かな雰囲気で進めていきたいものです。

これからIT革命的なことはここに書いていきます。

Permalink | Leave a comment  »