Yahoo! ブログの転載機能2006年12月07日 03時04分37秒

TB どもです。やっと話が見えてきました。

なるほど。Yahoo! ブログには、Yahoo! ブログシステムローカルで機能する「転載」機能が存在し、転載したい記事の「転載」ボタンを押すだけで、自分の Yahoo! ブログに記事を転載できるようになっている。この機能を中心とした話題だったわけですね。

昔、試しに使っていてそのままにしていた Yahoo! ブログがあったので、自分のブログだけで転載機能を試してみました。

自分で試して見て解った点を以下に列挙します。

  • 転載機能を用いてコピーした記事は、編集できない。転載時の内容がそのまま保たれる。
  • 上記で転載元と転載先の内容が異なるのは、転載を行ってから転載元を編集しなおした為。この場合、現時点では、転載元と転載先の記事は同期しない模様 (つまり、ハードリンクのようなものではなく、あくまでコピーであるということ)。
  • オリジナルの記事を作成もしくは編集時に、転載機能を許可するか拒否するかを設定可能。
  • 転載機能によってコピーした記事は編集できないため、転載を拒否する設定に変更することはできないっぽい。転載元の記事がコメント・トラックバックを受け付ける設定の場合は、これらも拒否する設定には変更できないっぽい。

この機能を実装した Yahoo! は、サーバーのキャパシティによほどの自身があるのでしょう。。。

個人的な見解を申し上げます。

Yahoo! ブログが機能として提供している以上、Yahoo! ブログシステム内の仲間同士で、この機能を用いて記事の転載を行いあうこと自体は、多くの場合、それほど問題は無いように思います。

ただ、「転載」という用語自体はごく一般的なものですので、「ご自由に転載してください」のような記述をした場合、Yahoo! ブログ以外のブログ等をもつ人が、手動で記事をコピーし、転載する行為も認めることになるという点には、注意する必要があるかもしれません (Yahoo! ブログが SNS だったならば、問題にはならないのですが)。

あとは、まぁ、各自の良識の範囲内で使われればよろしいのではないかと思います。

世の男性諸君はよく読んでちゃんと理解しておくように。2006年11月30日 16時11分26秒

微妙に関連するかも。いや、しないか。

しかし月経周期を報告させてスケジュールに組み込むってのも何だか尋常ならざる管理完璧主義だな。数ヶ月先を見越して、月ごとにスケジュールに余裕を持たせておくのが正しいスケジューリングなのでは? 女性は月一ぐらいで辛い日があることを想定してスケジュールを組むのは正しいけど、辛い日がどの日とどの日であるってわかってないとスケジュール組めないよーなんてのはむしろスケジュール組む側の人間が無能なんじゃねーのかとか思わずにはいられないわけだが。保守業務だって、この日は彼女は辛くなるから替わりに誰々さん入ってねじゃなくて、いつ誰が辛くなっても大丈夫なように人員配置&教育しておくべきなんじゃないの? って気がするんだが。

「実際そうそううまく行くもんでもないんだよ」なんて泣き言が許されるんなら、そもそも月経周期の報告義務ぐらい勘弁してやれよと。

ついでに、冬季は全員が一度はインフルエンザで一週間ぐらい休んじゃうことを前提にスケジュール組むとよろしいんではないかと\(^o^)/。年度末に向けて一番忙しくなる時期? そもそも年度末に向けて仕事を溜め込む文化をどうにかしろと。

運用のずさんなPSE法2006年02月24日 10時58分41秒

2ページ目参照。これはひどい。。。

自己組織化2006年02月15日 16時46分07秒

今後、おいらがそんな大量の部下を抱える立場になることがあるかどうかは分からんが。。。

プロジェクトがあまりにも大掛かりになってしまって制御しきれなくなってしまうような場合、すべてを把握し制御しようとするよりは、ルールを単純化して適度に自主性に任せてしまったほうがうまく行くことが多い、ってことなんかな。

とか思いながら、3ページ目の実例を見て、目からうろこがでますた。うわぁぁ、これだよ。おいらが求めていたものは。

朝・夕のミーティング、は個人的にはさすがにキツいなぁ、とか思ってしまうのですが、でもこれは朝食を普段あんまりとらない人がたまーにしっかり朝食を食べようとすると重いと感じるのと同じことなんだろうなと思う。慣れれば緊張感は持続できるし、無駄なペンディング要員も極力減らせるんではないかと思う。

それから、WSS はまぁどうでもいいとして、管理情報項目を極力シンプルにするという方法、特に、進捗状況の表現を、未着手、作業中、完了、中止の 4 つのみにしてしまう (個人的にはこれにさらに「凍結」を加えるといいと思う…あーでもそれって「例外」になっちゃうのか?) というやり方は、担当者が日報・週報を書く上で、進捗の度合いについてあれこれ考える必要が無くなるという意味でも非常に有効だ。進捗の程度を数字で表さないことにより不足する情報は、作業項目の細分化によって補えばよいことになり、その方が、何が終わっていて何が終わっていないのかが把握できる、と言う意味でもむしろ明確であると言える。

だいたい、数字を表す手段が「感覚」でしかないものを、何が何でも数字にして表さなきゃならないと言う風習、正直好きになれなかったのよね。たったそれだけのことで、どれほど胃を痛めたことか。そんな数字の分析に時間を割くくらいなら、まだ終わっていないこっちの仕事をさっさと片付けさせてくれ、って話なのだ。

ちなみに、どんな些細な問題でも障害として報告する、というルールを今の職場に浸透し徹底させたのは、多分、いや恐らく、間違いなくおいらだ。何が重要で何が重要じゃないか、なんてのは人それぞれ価値観が異なるのは当然のことで、「そんなことわざわざ報告するなよ」などと言ったが最後、重要な報告が上がってこない、悪しき「空気」が蔓延ることになる。品質管理における問題として、それだけは絶対に避けなければならない。

ええっと。。。ネットマナーとルールのお話でしたっけ?2006年02月09日 18時28分40秒

ヲチってカテゴリを追加するべきなんだろうなぁホントは (^_^;

議論が大げさで分かりやすくていいね。w

おいらは Web の安全性は運営者のポリシーに任されるべきだと思っています。プライオリティーを示すならば、以下の通りです。

  1. アカウントを持つユーザーが、損害を被らないこと (SQL インジェクションや XSS 脆弱性等による重要な個人情報の流出、等)
  2. アカウントを持つユーザー以外の人間が、損害を被らないこと (他所の個人情報を奪取する為のトラップ設置、トロイやワーム、スパイウェア等の積極的な配布、踏み台としての利用、等)
  3. アカウントを持つユーザーが、迷惑を被らないこと (一部ユーザーのマナー違反や DoS 攻撃等によるサービスの停滞、spam やマルウェア等の受信、等)
  4. アカウントを持つユーザー以外の人間が、迷惑を被らないこと (spam やいたずらレベルでのマルウェア等の配布・送信、ブラクラの設置、等)
  5. 有害情報の取り扱い (人権侵害、ポルノ等)

他にもあるかも。あと、分類の中で示した例は、場合や価値観によっては別の分類になる可能性もあるからあんまり責任はもてねっす (^_^;;

んで、これらのうち、確実にシステムで防がなければならないのは 1 だけです。何故なら、それが運営者側が直接の取引を持つアカウントユーザーに対して、最低限果たさなければならない責任の一つだから。

で、それ以外については、運営者がおのおの独自にポリシーを決めて対応すればよいことかと思います。全てを絶対にシステムレベルで制限しなければならないわけではないし、かといってこれらを絶対にシステムレベルで制御してはいけないということでもないと思います。

ブログなんかの場合、普通に Web サイトを 1 から構築するより簡単だということもあって、かつてよりもライトなユーザーの率が高いように思います。そういった方々はそもそも Javascript という存在自体知らなかったり、興味がなかったりすることが多いでしょう。ニーズがないなら、安全側に倒しておいたほうがいい、という考え方もあります。

それどころか、(おいらはこういう議論ではいっつもこいつを引き合いに出すわけですが) Yahoo! ブログなんかは、ブログ記事中でおんなじ文字を連続して何個か以上 (確か 5 個だか 6 個だか、それも無害そうな全角文字とかでも) 並べて書いただけでも、投稿時にエラー扱いにされます。他にも、禁止されたパターンというものがあそこはいろいろあるみたいで、原因がわからずにエラーが表示され、その上書いていた内容が消し飛んでしまうので、あっちゃこっちゃのユーザーが溜まったストレスを記事中に噴出させています (つまり、システムに対する不平不満がそのままネタになっている)。それでも、あそこはそれなりに活況です。そんな不便を考慮しても余りあるほどの魅力が、そこにはあるからなのでしょう (確かに、Yahoo! ポータルとの融合、コミュニティーツールとしての活性という意味ではかなり魅力的ではあると思います…ヲレは二度と使いたくないけど -_-;)。

大切なのは、システムレベルでは防がない事柄について、運営レベルで抑止力が機能しているか、という点です。ブラクラブログを運営の窓口に通報しても何の対処も施さないようでは、確かに公益に反していると言わざるを得ないかと思います。

運営レベルによる抑止力という意味では、国も法整備をちまちまと進めているようです (こっちはあんまり詳しくないけど。。。個人情報保護法とか、spam 禁止法とか、有害コンテンツへの取締り的な内容のものとか)。企業のコンプライアンスの重要性が叫ばれているような時代ですから、今の流れのままで行くならば、それほど悲観的になる必要もないんじゃないかと思いますよ。

ブログサービスは XSS 脆弱性を気にするな! という提言2006年02月06日 14時21分18秒

さて、任意の JavaScript の使用を許可しているサービスで、はまちやさんのような悪党(脆弱性を見つけたなら静かに通報すればいいものを毎回くだらない騒ぎを起こす愉快犯について私は悪とみなす)が続出してたいへんなことになっているか? なっていないのが実情です。個別に取り締まれば済む話になっている。はてなの XSS 対策は、むしろハッカーの挑戦を呼んでいるだけのようにも見えます。労力をかける方向性が、何か違うのではないか。

「d.hatena.ne.jp 以下のコンテンツでスクリプトの悪用はありません、なぜならはてなが特別に許可したスクリプト以外は使用が制限されているからです」という安心感を売り物にしようとしているのだろうけれど、現状、これはむしろはてなダイアリーの不便さと認識されていると思う。「なんでサイドバーの折り畳みができないの?」という話。いろいろなブログパーツのほとんどが、はてなでは使えない。戦略ミスじゃないのかな。消費者に理解されない安心感、誰もが気付く窮屈さ。

本当に「たいへんなことに」なっていないかどうかは、実はわかってない可能性もあるんだけどね。XSS アタックって普通は気付かれないように仕込むものだし。

だから、こっそり XSS アタックを仕込んでいるユーザーを、はてな親元が見つけ出して、個別に取り締まることができるかどうかは、激しく疑問。はまちやみたいな愉快犯ががんばっているうちはまだ華で、これが蔓延してきちゃうと、(はてなって場所が単なるブログサイトではないだけに) ちょっと困ったことになってしまうかもしれない。

ただ、やり方はともかくとして、「窮屈さを取り除く必要性」という点についてはおいらも激しく同意。実はこの辺の問題は、おいらも個人的にちょっと思うところがあって、実際に Web アプリとしてブログサービスを運営する立場であれば、自分が管理するサーバーはどうとでも扱うことができるわけだからいいんだけど、CMS プログラムを配布する側の立場に立った場合、プログラム側で XSS 脆弱性にあらかじめ手を打っておくべきなのか、あるいは運営者側に対策を任せるべきなのか、という部分で線引きが微妙になってくるような気がするのよね。ドキュメントに注意事項として明記したところで、文句言う人は言ってくるだろうし。。。(←ネガティブすぎる思考)

ちなみに。

不勉強なのでわからないのだけれど、管理画面のドメインを変更するのは難しいのかな……。

技術的には可能。(`・ω・´)つ[バーチャルホスト]

あとはまぁ、「d.hatena-manager.ne.jp」みたいなドメインでも取得してくればいいという話。お金はかかるだろうけどね。


Mon Feb 6 14:45:16 JST 2006 - 追記

肝心なこと書き忘れてた。。。

現状はてなが新しいドメインを取得したところで、即解決とはならねっす。まずは「管理用のドメインは xxx にしたから、現状 *.hatena.ne.jp で保存されている cookie は各自ブラウザから削除しておいてね!!」というアナウンスを物凄く徹底的にやっておかないといけない。そのための予備期間をある程度設定しておいて、窮屈な機能制限を取っ払うのはその予備期間の後にする、とか。

古川氏ご立腹2006年01月29日 19時55分45秒

主にレイアウトの変更に対する要望 (というか、苦情)。MSN Blog 開発チームは前社長をブログに参加させていると言うリスクについてあまり考慮していないのだろうか?

ちなみに、閲覧者側としても報告しておきたい不具合があります。おいらは古川さまのブログを、RSS フィードGoogle パーソナライズドホームに登録して閲覧しているのですが、現在この RSS フィードが指し示す記事への URL が、実際の記事の固定リンク URL とは一致しない間違った URL になっており、その為閲覧したい記事が正しく表示されないと言う状態になっています。これも是非、修正して頂きたく存じます。

古川氏の要望すら通らないのに MSN ブログユーザーですらないおいらがいくら我侭言ってみたところで反映されることなど到底ありはしないのでしょうが。。。;-p

Webアプリ セキュリティ2006年01月25日 13時29分00秒

内容的には次回のほうが有用そうですが(´¬`)。

具体的な対策方法に関する関連リンクとして挙げられてたうちのこいつぐらいは目を通しておこうかな。

あなたは、どっち?2006年01月11日 21時49分14秒

。。。漏れ、思いっきし管理者タイプだwwwww

つか、G はどう考えてもプログラマタイプだなwwwwwwwwwwwwww

自分という人間に見合った服を新調してみませんか?2006年01月05日 22時09分52秒

。。。こういう記事を紹介すること自体、なんとなーく、心苦しいものがあるのですが。

Fさんは、心から尊敬しあこがれの存在であるバリバリ上司と自分を比較し、「バリバリ上司に比べてできない私」という低い自己評価を常に抱えていました。昇進後は「私もバリバリ上司のようにならねばならない」という完ぺき志向を持って、必死でマネージャの役割を果たしてきました。

その結果、「私が上司に対してそうしたように、あなたたちも私に付き従うのが当然でしょう」という無意識の思いを、部下たちに押し付けることになってしまったのです。人一倍きまじめで責任感が強く、モチベーションの高い人ほどこうした状況になり、悩みを抱え込むことがあるようです。

。。。モチベーションの高さまでもが関係あるかどうかは微妙なんだが。。。「何に」対するモチベーションか、ってとこかな。仕事というものを無機質に捉えている人間にとっての、仕事を完遂すること自体に対するモチベーションに限定するなら、まぁ分かるような気はする。

ちなみに、強調はおいらによるもの。心当たりのある方は要注意です。こういうのって、自分で気が付いて考え方を改めるってのは、正直難しいんじゃないかと思う。