昨日、一時的にサービスが落ちていました。

15時くらいにサーバの1つが突然繋がらなくなり、何かやっちまったのか(例えばデータベースへの過剰なアクセスとか)と思ってサーバを再起動してみたのだけど全然ダメでおろおろしていたら、しれっとこんな告知が出てました。

メンテナンス・障害情報・機能追加|さくらインターネット公式サポートサイト

平素よりさくらインターネットをご利用いただき、誠にありがとうござ います。 本日、ご提供サービスにおきまして、以下の通り障害が発生いたしました。 ご利用中のお客様には大変ご迷惑をおかけしておりますことを深くお詫び 申し上げます。

影響範囲 : さくらのVPS 1Gプランの一部 IPアドレスが下記の範囲のお客様 219.94.245.15 ~ 219.94.245.134 障害内容 : サーバに接続できなくなる障害が発生しました。 障害によりVPSの意図しない再起動が発生しました。
ああうん、ドンピシャだよさくらさん。 いままでここまでビシッとターゲットになったことが無かったのでちょっと驚きました。発生したのが15時20分で復旧したのが18時05分。何が原因か解らないけど(機材の故障かなぁ)さすがに3時間とめられるのはきついなー。まぁ、障害発生は仕方ないか。ただせめてメールでお知らせくらいして欲しいなーと思いました。障害情報をRSSで読むといっても、それを読むRSSリーダーが今障害が起きているサーバに載っていたので。 とりあえず、データに何の問題も無くて良かったです。やれやれ。

続きを読む

きちんとしたエンジニアと話をするとき、僕はとても緊張する

「きちんとしたとは?」という話はあるけれども、 「コードとはどうあるべきか」を知っていて、コードを読んでそれが巧いか拙いかわかるという普通のレベルのエンジニアの人と話すとき、僕はとても緊張する。とある流れで面接的なものを受けたときも、それで酷く緊張して頭が真っ白になり「自分の得意な言語でループを効率的に書け」と言われただけなのに関数どころか書式もなにもかもが全く出てこなくなってしまって、お互いにこれは困ったねという顔をするしか無くなってしまった。もちろん、その話はそれで無しになった。書面だけでお祈りされることもなくせっかく京都から浜町まで行ったのに。ガッデム。ガッデム俺。 なぜとても緊張するのか?と言えばそれは要するに自信がないからだ。 自分なりに勉強しコードを読み、やり方を年々変化させてなんとかプログラマらしくなってきたけれど、他人にコードを読んでもらう機会がほとんど無く、自分のやり方が妥当なのかどうなのかという自信がない。コンプレックスと言ってもいい。良いとされるもの(例えば:アジャイル)を求めてしまって、それと自分の差を見てまた自信がなくなってしまう(本当はそれが今の自分のプロジェクトにとって最適かどうかの検証が必要なのだけど)。そんなの気にしなければいいじゃんといつも思うのだけど、きっとプライドが高いんだ。「ダメだこいつ」と思われたくない。つーか怖い。 だから、きちんとしたエンジニアの人と話をすると、ダメ出しを恐れてとても緊張する。 でも最近少し学んだことがある。 自信がないことや、もしかして本当に能力が足りないことや、緊張することは仕方がないけれども、緊張しながら言うべきことをまとめて丁寧に伝えることは出来る。 最初に大事なことは「聞かれたことだけを考える」。先回りして補足しておこうとかしても話が錯綜するだけだ。それよりもまず質問に回答を用意することを優先する。 次に「解らないことは解らない」と答える。なんでもかんでも解らないのはダメだが、解らないことを説明するのはあとでいい。全体としてはっきり掴んでいるわけではないことについて言及するときは、解っている部分と解らない部分を分けて解るところだけ明確に答える。解らないところを曖昧に答える必要はない(と考えておく)。 最後に「ゆっくり話す」。考えながら話さなくて良いから、いつもよりゆっくり話すことを心掛ける。早口で話すとその自分の口調に煽られてさらにテンションが上がってしまう。ゆっくり話すとだんだん周りが見えてくる。周りが見えたところで僕が優秀なエンジニアに化けるわけでは全然無いけれど、言いたいことは言えるようになる。 もちろんベースとしては、自信のなさを何とかしないことには根本的な解決にはならなくて、そのためにはコードを読んでもらう人を確保するとか、コードを公開するとか、もっとソースコードをたくさん読むべき。他の言語の実装ももっと見るべき。そういうことは解っているのだけど、そして努力を始めているけれど、今現在足りないという場面に対面したときには、上に書いたようなことを心掛けながらその時の100%を出せるようにしたい。 こういうの、意識しなくても出来る人もいるんだよなぁ…それは素直に羨ましい。いやまじで。

続きを読む

【メモ】 PDOで空文字をNULLに変換する

#需要がどれだけあるかわかりませんが PDOを使ってデータを取得する際に、空文字をNULLに変換して取得することが出来ます。 PHP: PDO::setAttribute – Manual

PDO::ATTR_ORACLE_NULLS

NULL と空文字列の変換 「ORACLE」とありますが、Oracle だけでなく、全てのドライバで利用可能です。

PDO::NULL_NATURAL

変換しない

PDO::NULL_EMPTY_STRING

空文字は NULL に変換される

PDO::NULL_TO_STRING

NULL は空文字に変換される

使用例

$connection = new PDO( 'mysql:dbname=dbname;host=your_host', 'user', 'pass' );
$connection->setAttribute( PDO::ATTR_ORACLE_NULLS, PDO::NULL_EMPTY_STRING );
PDOの設定ってだいたいライブラリの中にあるし、魔法の呪文みたいになってて意味をいちいち見ないけど、 たまに見ると面白いなというそんな話。

続きを読む

MLBのデータはXMLまたはJSONで取得できるらしい

イチローの打率が気になるので、どこかからデータを引っ張ってきてグラフ化したいなぁ、できれば毎日更新でとか思ってたんだけど、ニュースサイトをパースするのも何か面倒だしましてや手入力とか。どこかでCSV配布してるサイトとかないのかなぁとか思ったらば、なんとMLBが全選手の全データをXMLで提供していることが解って驚愕。マジか。 正確に言うと、「Gameday」っていう今日の注目試合みたいな企画のためのデータベースなのだけど。 MLB.com Gameday | MLB.com: Gameday これがオープンになってて自由に使えるみたい。 データベースはRESTチックにアクセスできそうな階層になっててルートはここ。 http://gd2.mlb.com/components/game/mlb/ 探せば色んなデータが手にはいる。すげえ。

続きを読む

Amazonアフリエイト用テスト

目的

Amazonの商品ページを開いて、そこからなるべく少ないステップでブログエントリに貼り付けるアフリエイト用パーツを取得できるようにする。

やったこと

  1. ASINなどを与えるとその商品の情報を取得し整形して表示するプログラムを作成
  2. Amazonの商品ページでアフリエイト用パーツを取得するBookmarkletを作成

1. ASINなどを与えるとその商品の情報を取得し整形して表示するプログラム

大体次のような感じ。
  • PHPベース
  • フレームワークはSymfony
  • PEAR::Services_Amazonを使用
【メモ】 PEAR::Services_Amazonを使って商品情報を取得(署名認証対応) – nplll サービスURLはこんな感じ。
  • //amazon.nplll.com/asin/[Amazon ASIN] → 特定の商品の情報を表示する
あ、一応オープンになってますが、あくまで自分向けなので突然サービス終了することもありますし、 アフリエイトIDを追加することも出来ません。

2. Amazonの商品ページでアフリエイト用パーツを取得するBookmarklet

AmazonのページからASINを抜き出して整形するBookmarklet
javascript:function%20getID(id){return%20document.getElementById(id);};var%20u=location.href,d=/(http:\/\/www\.amazon\.(com|co\.jp))/;if(u.match(d)){t=getID("btAsinTitle").innerHTML;r2=RegExp.$2;if(r2=="co.jp")l="amazon.jp/dp/";else%20if(r2=="com")l="amzn.com/";else%20exit();l='';prompt("%E3%80%8C"+t+"%E3%80%8D",l);void(0);}
例えばこのページで実行すると↓ Amazon.co.jp: THE BEST OF スチャダラパー1990~2010: スチャダラパー: 音楽 こんなのが取れます。↓
実際の表示はこんな感じ↓

続きを読む

【メモ】 DOMDocument::loadHTMLで文字化けする場合

HTML文書を読み込んでパースするときに、今までは正規表現でやっていたんですが、 処理がどうしても面倒な感じになるし改変にも弱いので、DOMでやることにしてみたらば見事に嵌るなど。 読み込む文書がXMLだと問題ないんですが、HTML、特にShift-JISで書かれた文書だとなぜか文字化け。 色々と検索した結果、多分これで行けると言うのにたどり着いたのでメモ。

参考

DOM拡張モジュールでHTMLをパースする【PHP】 – Programming Magic

文字化けさせないためのポイント

  1. 読み込む文書をUTF-8に変換しておく
  2. あらかじめ日本語文字列を数値文字参照に変換しておく

1. 読み込む文書をUTF-8に変換しておく

PHPのデフォルト文字コードに合わせる、と言う意味です。

2. あらかじめ日本語文字列を数値文字参照に変換しておく

よく解らなかったんですがこれが文字化けの直接できな原因のようです。 参考エントリでは「metaタグで文字エンコードが指定されていない」場合に起きると書かれていますが、 文字エンコードに「Shift_JIS」が指定されていても発生しました。 というわけで、あらかじめ日本語文字列を数値文字参照に変換しておきます。
$html = mb_convert_encoding($html, 'HTML-ENTITIES', 'ASCII, JIS, UTF-8, EUC-JP, SJIS');
これだと、表示上文字化けは起きません。 それどころか、コメント以外の部分は普通に日本語で書き出されているようです。 ので、このままでもいいかなーという感じ。 まぁとはいえ、あんまりDOMについて解っていないので、だいぶ泥縄であれこれやってるんですけどね… サーバの全面引っ越し(およびドメインの変更)はいつになることやら。

続きを読む

【ニコニコ動画】 障害が起きるのは仕方がないと思うんだ

なんでかっていうと、ソフトウェアの問題ならともかくハードウェアなんでしょう?「障害を予期して」なんて昨日は書いちゃったけど、ハードウェアだったらまぁ無理。本当は二重化してなきゃいけないんだけど、資金の都合で出来ないんだったらもう仕方がない。障害が起きるという前提で、そこからどうするかが求められるわけですよね。ええ。 一番大事なのは素早い復旧。初動の問題については川上さんも言及されてるけど、復旧に掛かった時間を考えると初動が1時間早かったら問題にならなかったかって言うと別にそういうわけではなさそう。 次に、障害情報に関する告知。これは戀塚さん関連のまとめにもあるけどちょっと遅すぎ。別に恋塚さんが動いたから解決したわけではないのだろうけど、でも印象としてはそうなっちゃってる。その間に右往左往したユーザーにとって見れば「運営は修正する気がない!」。何時間も動けなかったんだったら仕方がないけど、既に復旧作業を始めていたにもかかわらず「作業始めるのが遅い」と思われていたんだとしたらそれは何というか本当に勿体ない。現場のエンジニアの人たちのことを考えると心が痛い。広報もっと頑張れよ。 最後にプレミアムの扱い。夏野さんの発言は放っておくとしても、プレミアム回線にだけ障害が起きた場合、一般回線を空けてそこにプレミアム回線を振り分ける…という仕組みはできないもんなのだろうか。ただの混雑とは種類が違う作業になるんだろうけど、想定しておくべきなんじゃないのかな。

何が悔しいのかというと。

他の人はどうか知らないけど、僕の認識では「ドワンゴ」「ニワンゴ」というのは技術屋の集まりで、基本的にあらゆることを技術的アプローチで解決していって素晴らしいサービスを作り上げたと思ってるんだけど、その技術屋集団が起こりうる障害に対して諦めるしかない、と思っているところ。現場はそうは思ってないかも知れないし忸怩たる思いかも知れないけれども、現状ある解決策に対する資金面での判断は「無理」なわけで、逆に言えば資金に適う解決策がないってこと。それが何か悔しい。 技術で障害を回避するのが不可能だったとしてもその後のアプローチを技術的に改善することは出来たはずで、結構そういうところの技術ってあるはずなのに出来なかったってことは、単に「やらなかった」ってことなのかなぁという。そういう技術屋が負けた感を勝手に感じていて、それが悔しいというか、残念というか。 いや、それでも何とかしてくれると僕は信じてる。 むしろ、3ヶ月後くらいに同種の障害が起きて欲しいなとも思ってたりしてw そこで見事な対応がなされたら、技術者としてはもの凄いカタルシスを感じるよ。

参考

続きを読む

【tips】 PEAR::Cache_Liteのディレクトリ構造を深くする

レンタルサーバではmemcachedなどを使用することが出来ないので、何らかのファイルキャッシュを使うことが多いと思うんですが、いくつかのサービスではPEAR::Cache_Liteを導入しています。 Cache_Lite 規模が大きくなるとI/Oがネックになるので、ファイルキャッシュはいずれ問題になってくるのですが、小規模なサービスであればこれで十分。 で、導入自体は極めて簡単なんですけど、気になったのはディレクトリ。UNIX系サーバでは1ディレクトリにおけるファイル数は10,000くらいなので、サービスを継続しているといずれキャッシュが作れなくなってしまう。でもCache_Liteの設定(インスタンス生成時にオプションを配列で渡す)ではディレクトリを渡すだけ。今は大丈夫だけど念のためディレクトリを構造化したいな… と思ったら、ちゃんとその設定がありました。 マニュアルは細かく読まないとダメだね。

続きを読む