[ネットライフ]regexpでdis祭りの予感

過去にも同じような光景を見た気がするが、気のせいだろう。。。

「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ - 404 Blog Not Found曰く、

正規表現って、プログラミング言語間の差が少ないサブ言語なのに、なぜ「PHP」がつくとダメ正規表現ばかり登場するのか。うんざりだ。

かなり煽っていますね。。。

で、はてブにおける問題のエントリのブックマーク状況。
はてなブックマーク > かなり使えるPHPの正規表現まとめ - IDEA*IDEA ～ 百式管理人のライフハックブログ ～

これは痛々しい。本当に便利だとおもってそのまま使いまわす雰囲気がある人たちが多数集まっていらっしゃる。また、この状況を皮肉っている人も少数見受けられる。

ブックマークする事自体にケチつける気はないし、他所様のソースを参考にするのも悪いことじゃないと思うんだけど、これらのregexpをちゃんと吟味しておいたほうがよさそうですよっと。

もっとも、今回のケースでは元ネタのregexpサンプルがあまりにもアレだったにもかかわらず、とくに吟味せずに取り上げたのが問題なんですがね。

色々考えさせられる一件です。。。

3/19 追記
要するに、ちょっと思考停止しすぎなんじゃないかと思った次第。
開発者なら、単純なチェックをさせるための正規表現は、自力で書けるようにしておきたいものです。

さらに追記
今見たら、かなり祭られている模様。たしかにあの煽りは蛇足と感じますけど、dankogaiらしいとも思います。

[視点]もっとチケットという言葉を浸透させないか？

バグに至るまでの道のり - がるの健忘録を見て、切に思った。

まず「実装バグなのか？」という部分で、大抵の心ない人非人*2が予想しているよりも多くのハードルがあったりします。

（中略）

*2：えと…it(それ)とか呼んでみるのはどうかしらん？ きっと彼らは「ITかぁそうかぁ俺たちが代表なんだなぁ」とか都合良く勘違いしてくれそうですしｗ。えと…「ITな人たち」「ITな方々」とかいう言い方？ｗ

ここでいうITな方々に相当しそうな人たちって、概ね「開発者より権力のある、開発者ではない人」に相当するとおもう。仮にそうだとすると、潜在的にはかなり多くの人たちが該当する。

で、彼らが開発者に「バグだ」と言って持ってくるものって、大抵「バグかもしれない事象の報告」だったりするわけで。でも、「バグ」って言葉は認知され、発音しやすく、しかも衝撃的なので、皆こぞって「バグだ！」と言い続ける。
# 理由はもっと他にあるかもしれないけど、体験上よくあるパターンとして。

言うだけの人からすれば、まあそれで良いんだろうけど、「バグ」を出したとされる開発者からすれば、これは堪ったものではない。何が堪らんのかというと、バグかどうか分からん事象までバグ扱いされて、全部自身の責任にされ兼ねない。こりゃつらい。下手すると次の日から音信不通になるかもしれない。

開発者や「ITな方々」を含め、いろんな人が不機嫌になるくらいなら、最初から「バグ」なんて言葉を不用意に使わなければ良いだけの話だと思う。

「バグかもしれない事象の報告」や「修正要望」は、「バグ」ではなくて「チケット」ですぜ。

チケットについては、第3回：チケットドリブン開発でバグ削減！に詳しく説明があります。

「ポジティブ」だけが要素じゃない。

http://d.hatena.ne.jp/tokuhirom/20081103/1225670242

これはものすごく共感できるし、現実にそういう状況にしょっちゅう出くわす。
成果を出したいという思いだけでは、成果は出ないのです。
悲観的な情報も考慮し、それに対処していく必要も出てくる。
これに感情的な反論を加えられる事もよくありますけど、それは悲観的要素から目を背けているに過ぎないし、そういう情報の提供者を攻撃すること自体もそもそも間違い。

[電波]クレーマーの法則発見か？

それなりにこの業界(IT)に身を置いているが、最近感じたこと。

　ケチほど精神論

よくあるのが、報酬(お金に限りません)を出す気配もないのに、つい熱くなっちゃって「技術者としての意地を見せてください！」とか言うパターン。

報酬＋αくらいはこなしますが、それ以上を求めるのは如何かと。

個人間ベースで言われるのは結構なことだけど、ビジネスパートナーとしてこれ言われると、ちょっと距離おきますね。。。

そりゃオイラは技術者だし、意地もあります。でも、はっきり言ってこういうのは、根っこが強請りと同一だと思う。

で、こんな事言うと、むしろオイラがケチといわれるオチがｗｗｗ

[視点]サービスを提供するということ

サービスを提供する上で不可欠な事柄として、以下のものが挙げられよう。
・企画
　サービスの根幹となる発想や決まり事、利用者からの要望を取り入れたアイデア等を用意する。
・開発
　企画から挙げられたアイデアや決まり事を形にする。
・広報
　サービスの存在や特長を宣伝する。
・運営
　利用者からの要望、質問、クレーム等の窓口となる。
・運用
　サービスを安定稼働させる。

大抵は、これらの他に会計が加えられるのだろうが、会計はサービスに直接関与しないので、割愛する。
これらの内、どれか１つでもおざなりにしてしまう様では、サービスにとって致命的な問題となる。以下、想定される状況を挙げてみた。

・企画がダメな場合。
　・よくわからないサービスになる。
　・使いづらいサービスになる。

・開発がダメな場合。
　・使いづらいサービスになる。
　・サービスの質が悪くなる(レスポンスが悪い、見た目が酷い等)。

・広報がダメな場合。
　・利用者数が伸びない＝流行らない。
　・何故か悪評が付き、悪評だけが独り歩きしだす。

・運営がダメな場合。
　・利用者からのクレームが殺到。最終的に利用者が激減する。
　・よくわからないサービスになる。
　・悪評が付き、他に運営しているサービスにも悪影響を及ぼす。

・運用がダメな場合。
　・不安定なサービスになる。
　・サービスの質が悪くなる(レスポンスが悪い、見た目が酷い等)。

最近よく見かけるパターンは、運営と運用がよろしくないというものだ。
というのも、（ここで会計が絡んでくるのだが）経営サイドが運営や運用にあまり投資したがらないのが大きな理由の１つのようだ。
実際、運営や運用というのは、一見生産性が無いように見える。しかし、これらはサービスを維持する上で致命的な役割を担っているのだ。いわば、運営・運用している時点で、失う予定の利益を確保しているわけだ。

是非サービスを提供する側の方々には、骨太な運営・運用を検討していただきたいものだ。