ただつらつらと日記が書かれていくようです。
はてなダイアリーにtwitterのwidgetを貼り付けられることは、はてなダイアリーのヘルプでわかった。で、twitterにログインしてみると、ユーザ情報のところに「(あなたのWEBサイトにもTwitterを表示させよう)」ってリンクがあって、それをクリックするとwidgetを表示するためのHTMLを入手できる。
…が、しかし。
Twitter Widgetはシンプルなやつとリッチなやつがあって、シンプルなやつはそのままではてなダイアリーのサイドバーに収まるけれど、リッチなやつは収まりきらない(汗)で、どうしたもんかと思っていたら、<object>タグのなかにwidthがあったのでいじってみた。twitterからもらってきたHTMLはwidthが290だったけど、はてなダイアリーのサイドバーにあわせて200くらいに。あと、<embed>タグにも290なwidthがあったので、それも200にしてみたら、なんとなく収まった。
やっぱりリッチな方がよさげな感じ。
なんだか、楽天界隈が騒がしいなぁと思ったら、読売新聞にニュースが出てて、楽天が応戦してた。
no titleとか、 【楽天市場】エラーの「読売新聞の記事に関しまして」とか。
以前、楽天から顧客情報がどーっと流出した事件以降、楽天の店舗に提供する個人情報を限定して、メールアドレスやクレジットカード番号を提供しない措置を取ると言っていたものの、実は大量に注文を受ける店舗など、9つのお店にはしっかり提供していたってことらしい。なるほど。
で、上記の読売新聞の記事より。
一方、利用者の間では「個人情報が漏れているのでは」との不安も出ている。千葉県内に住む男性会社員（３２）によると、楽天市場だけで使っていたアドレスに、あて名に会社員の本名が記された迷惑メールが大量に届いているという。
そういえば、最近、楽天市場での買い物くらいにしか使ってない、私のメールアドレス宛にスパムが届くようになったので、楽天周辺からスパム業者にメールアドレスが流出したんじゃないかと疑ってはいたところだ。でも、おそらく、9件のお店と楽天は、かなりの覚悟をして、メールアドレスやクレジットカード番号をやりとりしているはずだろうから、個人的には、楽天、もしくは、その9つのお店が発生源であるような気がしないんだけどなぁ。(1000件以上の注文を捌くお店が個人情報を流出させたら、事業に与えるインパクトはさすがにでかいだろうし…。個人情報を流出させちゃった企業は数多いけれど、ろくなことになってないのは知ってるだろうし。)
いや、そもそも、メールアドレスに関しては、楽天から正式に提供されていた9つのお店以外でも、入手可能だったんじゃないかと思う。
例えば、楽天で買い物をしたときに、システムが自動発行するメールの他に、お店側から「ご注文を承りました」的なメールが来ることがあるが、そのメールのCCに、お店のメールアドレスが入っていることがある。(なんとなくうろ覚えだったのだが、さっき、とある楽天のお店で買い物したときのメールを確認したら、やっぱりお店のアドレスがCCに入っていた)そのメールには私のアドレスが書いてあるわけだから、きちっと整理されたメールアドレスの束の形ではないにしろ、そのメールを受け取ったお店側で、いちいちメールからコピペすれば、スパム業者に提供可能なメールアドレスの束は作成可能だろう。…そんなわけで、どっちかというと、楽天から正式に提供されていた9つのお店よりは、ある程度の注文があるけれど、そんなにまじめに顧客情報管理してないお店からの流出するリスクの方が高い気がする。
ま、いずれにせよ、各ユーザの購入履歴を検索できるのは楽天だけだろうから、楽天側でスパム被害者のとりまとめをやって、被害者の購入履歴がかぶっているお店を調べれば、あっさり特定できそうな気がする…けど、最近の楽天を眺めていると、そこまでやんないような気がする今日この頃。
サービス停止中の「この指とまれ」のトップページが密かに更新されていた。
なにやら、サービスの管理業務が「ゆびとま再建委員会」に移管されたようだ。で、「ゆびとま再建委員会」ってなんぞやって見てみると。
「ゆびとま再建委員会」とは、このたびのサービス停止からの復旧と今後のさらなるサービス改善のために協力して頂いている複数の企業、および当サービスを日頃よりご利用頂いております数名のヘビーユーザの方々によって構成された組織です。
…え、なんで、「ゆびとま再建委員会」って組織に、ヘビーユーザーが参加するの？(汗)てか、誰なんだろう。それに(民主主義的である必要もないけれど)どうやって選ばれたんだろう。仮に、「ゆびとま再建委員会」が多くの個人情報を管理しているとするならば、なんとなくその辺も気になるな。
「ゆびとま再建委員会」では、復旧作業が長期化する場合も想定し、旧システムを破棄し、全く新しいシステムを新たに開発してサービスを移管することも視野に、同時並行で作業を進めており、６月１４日（日）のサービス再開を予定致しております。
なんとなくよくわからないけれど、「(旧システムでの)復旧までの作業が長期化する」場合を想定することと「(旧システムで?)6月14日にサービス再開する」ことは矛盾するような気がする一方、新システムを構築することと「(新システムで?)6月14日にサービス再開する」ことも、やっぱり矛盾する気がする(てか、新システムってそんな簡単に作れるんだっけ…？)。
…てか、「ゆびとま再建委員会」は何をどうするつもりなんだろう。
こんな記事(三角錐の体積が計算できない技術系新入社員—深刻な若手の学力低下)を見つけた。
最近の技術系新入社員の基礎学力の低下に関する話題の中で，「半数が三角錐の体積を計算できない」と聞いたからである。それだけではない。家庭の商用電源のおおよその電圧を尋ねる問題が解けない技術系新入社員も十数％いたという。驚くのはまだ早い。この電圧の問題はいわゆる「サービス問題」で，「○mV」や「△万V」といった選択肢が用意されている問題だったのである。いや，驚くのはまだまだ早い。この大手メーカーは，大学院修士課程修了者（修士卒）が技術系新入社員の8割を占める人気企業だったからである。
私が、とあるSIerに入社したときも、情報工学系の大学院で修士を持っている同期がいたけど、さっぱりプログラムが書けなかったのに衝撃を覚えてしまった(情報工学系の大学院を出てれば、多少なりともプログラムが書けるはずというのが私の思いこみ、勘違いだった可能性は高いけど)ことを思い出した。特定の言語ができないって感じじゃなくて、プログラムを書いたことないんだよねって感じで…(汗)
最近の新入社員の学力低下が著しいのかもしれないが、そんな彼らも大学や大学院で教えられる内容については、さすがに知っていて、その周辺部分というか、応用部分というか、横の広がりみたいなのが欠けてるのかなという印象を受けた。たぶん、「家庭の商用電源のおおよその電圧」なんて、大学の教科書に書いてないんだろうけど、好奇心を持って大学で教えられることの周辺をごそごそと本を読んでいれば、さすがに行き当たりそうな気がする(「家庭の商用電源のおおよその電圧」って、専門知識でもなく「常識」のような気がしないでもないけど)ただ、記事の後半を読んでみると、自分から知識や経験を獲得しようとする姿勢が欠けてるのかもしれないな。
ま、原因はさておいて、若手が与えられたものだけで満足して、与えられないと何もしないってなると、若手の知識も経験が与えられるスピードでしか増えていかないし、知識も経験の幅も深さも、与える側(ベテラン)を超えることはできないわけで、知識や経験の総体は小さくなっていくんだろうな。
NTTデータの山下社長が日経コンピュータのインタビューに答えている記事を発見。
おぉ、さすがはNTTデータ。山下社長がやろうとしていることが壮大だ。「3倍速の開発」ということで、地球の自転に合わせて、仕様書とかソースコードといった成果物が世界中を飛び回る(…というよりは、地球上で、起きてる人たちが成果物を常にいじくり回してるって感じか…)ようなシステム開発をやるんだそうな。
会社が24時間眠らないで、24時間連続して開発を続けられる仕組みを作りたい。例えば、日本で8時間設計したら、インドかヨーロッパで8時間製造し、それを南米に持っていって8時間試験をする。日本から見ると、朝来ると、自分が設計したソフトが製造され、一通りの試験が終わって手元に来ている。
確かに、実現できれば、システム開発にかかる期間は短くなりそうだし、コスト削減効果も得られるのかもしれないなぁと思う。
…が、しかし(汗)
もし、NTTデータが受託するであろう規模の案件を、ウォーターフォール風の従来の開発プロセスのまま、「3倍速の開発」に放り込んだら、単なるオフショア開発みたいになるんじゃなかろうか。例えば、設計は日本で何ヶ月かかけてやるんだろうし、その後の製造、試験はインドや中国あたりに投げてやってもらうみたいな。…って、たいして速度は上げられなさそうだ(汗)。
ということは、例えば、「設計して、作って、テストして」というプロセスをかなり小さくして、反復するような開発手法になるんだろうな。それも1日分の仕事を世界で分散するとなると、相当、細かくすることになりそう。でも、ウォーターフォール風の開発プロセスに慣れまくってる組織が新しい開発プロセスになじめるのかな。
あと、山下社長は、さりげなく「日本で設計して…」とおっしゃっているが、日本だけが設計工程を担当するよりも、もし、設計工程を世界中で分散できれば、開発速度は上がるんじゃないだろうか。そして、おそらくは製造、試験工程も同じことが言える(…むしろ、製造、試験の方が適用可能性が高いか…)ような気がするわけで、仮に、ウォーターフォール風の開発プロセスを採用するとしても、もし、世界中で、同じ仕事を同じレベルで分担できるのであれば、まさに「3倍速の開発」が可能なのかもしれない。
例えば、製造、試験工程であれば、日本でソースを書いたら、そのレビューとか試験を中国でやってもらって、さらに、インドで追記し、インド追記分のレビュー、試験をヨーロッパでやって、アメリカでさらにソースを追記し、そのレビューを日本でやるといったプロセスを延々と繰り返す…といった感じだろうか。
それは、この辺で山下社長が語っていることかも。
今でも、製造工程に入っている案件で海外に渡しているものはあります。例えば、日本で書いたソースコードを北京の子会社に送ると、北京の方でソースコードのチェックをわーっとやって、ぱっと返してくれる。こういうサービスは社内ではやっているんですよ。
でも、それはあくまでもソースチェッカーのところだけなので、もうちょっとロジックまで追って、びしっとやってみたいじゃないですか。自動生成したものも含めて、全体のロジックがきちっと確認できるとか、業務知識がからむところまで世界各国でやれるようになったら、すごく効率が上がると思う。
もし、そうなってくると、おそらくは設計書は英語で書かなきゃならないだろうし、ソースコードのコメントも、試験報告書もバグ票も英語ってことになるわけで、実は、日本の開発者が英語ができないこと(…あと、もしかすると、ソースコードを書けないこともか?)が、最大の障壁になりそうだが…根が深そうなので、この辺は簡単には解消しないだろうな。
確かに、「3倍速開発」は、NTTデータなどの日本のSIerにとってはチャレンジではあるんだけど、一方、世界的なパッケージソフト屋さんって、普通に、そういう世界分業体制を敷いてそうな気がするけど、どうなんだろうと、ふと思う。
もとい。
山下社長が興味深いことを語ってた。「ずっと気になっていたのだが、そもそもNTTデータの社員は開発をしているのか」という問いに対して、
非常に危機感を持っていて、現状は何しろ内製率が低い。正直にお話すると全部合わせても3割とか3割5分ぐらい。残りは協力会社の方々に手伝ってもらっている。
とのこと。
私、NTTデータで30%～35%も内製してたことに驚いてしまいました(汗)とはいえ、Intramartなんかのパッケージを作ってる部隊の数字も併せて全社平均してるような気がしないでもない今日この頃。。。
内製化率を増やしたいという考えは前からあった。そもそも大昔、電電公社がDIPSというメインフレームを手掛けていた頃は、みんな自分たちの手でプログラムを作っていた。それこそ私なんかも入社してからずっとデータベース担当だったから、設計の中身にまで携わってアセンブラまで使っていた。
…おっと、どっかで聞いたことある話だなぁ(笑)山下社長のような方が内製化を進めて「内製=コスト高」が目に見えるようになった頃に勇退。で、その後の偉い人が「コスト削減」を旗印に、外注率を上げていって勇退。で、次の人が、また危機感を覚えて内製率を上げていくということの繰り返しにならなきゃいいけど。
人生のどこかでプログラムを作る仕事を経験した方が絶対に面白い。一生やれと言われると少し考えるけれど。20代あるいは30代の前半くらいまでに真水の仕事をどれだけやったか、その後の人生の豊かさにつながります。
えーと、そろそろマジメに真水な(汗)コーディングしますか…ね(笑)
私は、長らく、さくらインターネットのレンタルサーバを利用しているが、直近のメンテナンスに伴ってサーバが交換されたようだ。
確か、私が借りてるサーバはPentium4で動いていたと思ったけれど、OSのバージョンアップと一部のサーバのハードウェアを交換するというお知らせが来たので、ちょっとコントロールパネルで見てみたら、使っているサーバのCPUがCore2Duoに変わっていた。CPUだけPentium4からCore2Duoに交換するってのは難しいので、サーバのハードウェアがごそっと交換されたんだろうなぁと。
さくらインターネットの社長のBlogによれば、負荷上昇が原因で、ハードウェア交換が実施された模様。
で、ascii24の古い記事によれば、さくらインターネットが個人向けのサービスを一新したのが2004年頃。で、おそらく私はそのサービス投入直後から使っている(…と記憶しているが…)はずなので、サーバはだいたい5年近く運用されて交換されたことなる。
今回は負荷対策ということなので、必ずしも寿命に伴う交換(まぁ、寿命が訪れてハードウェアを交換するんじゃ遅いわけですが)ってわけではないけれど、なんとなくサーバの交換時期に関して参考になるような気がした。
Nagiosの設定をつらつらと書いていたときに、Serviceのチェックはしたいけれど、IPアドレスにPingを打って死活チェックして欲しくないケースに直面した。例えば、ICMPパケットが通らないけど、HTTPは通るようなネットワーク(例えば、イントラネットからルーターを経由して、データセンターに置いてあるWebサーバを監視したいけど、そのルータがご丁寧にICMPパケットを落としてくれる設定になっていていじれない…みたいな)を経由して、Webサーバの死活チェック(とレスポンスタイムのチェック)をやりたいようなケースとか。こんなケースでHostCheckすると、ネットワークが原因でPingのレスポンスが帰ってこないもんだから、DOWNと判断してくれるのでうっとうしいなぁと。
で、Nagiosのドキュメントを読んでみると、max_check_attemptsの項目のところにさりげなく
To bypass the host check, just leave the check_command option blank.
って書いてあったが、blankにしても、「blank」って書いても設定ファイルチェックでエラーが検出されて、さっぱり先にすすまない(汗)ので、仕方ないので「check_dummy」プラグインを使って、とりあえずOKを返すコマンドを自作した。
とりあえず、こんなコマンドを定義。
# ‘return_ok’ command definition
define command{
command_name return_ok
command_line $USER1$/check_dummy 0
}
define host{
use linux-server
host_name HOGE
alias HOGE
address XXX.XXX.XXX.XXX
check_command return_ok
max_check_attempts 1
}
みたいな感じで呼び出してあげると、HostCheckの結果はとりあえずOKになる。こんな対処でいいのか疑問はあるけれど、とりあえず、ま、いっか(汗)
*1：例えば、イントラネットからルーターを経由して、データセンターに置いてあるWebサーバを監視したいけど、そのルータがご丁寧にICMPパケットを落としてくれる設定になっていていじれない…みたいな
最近、keepalivedなんかを動かすために、強烈なCPUパワーはないけれど、そこそこ動いて、低電力で小型なサーバがないものかと漁っていたら、SUPERMICROがAtomを搭載したマザーボードをリリースしたらしい。
「ページが見つかりませんによると、
サーバ向けをうたうSUPERMICRO製のAtomマザーボード。Atom 230搭載/デュアルチャネルメモリアクセス対応で、ICHには同種製品で初めてICH7Rを採用している。フォームファクタはFlex ATX。
紹介されているのは、Atom N230を搭載した安いモデルだけど、Atom N330(デュアルコア)で、かつ、オンボードでNICが2枚刺さっている上位モデル(「X7SLA-H」)がいい感じだと思われ。でも、NICが蟹さんってのがなぁ…あんまり好きになれないような気がするが、ま、仕方ない。
で、SUPERMICROは、このマザーボード用に(NECのハーフサーバ風の)1Uのシャーシもリリースするらしい。シャーシの奥行きが短いので、ラックの前と後ろと前からサーバを刺して、1Uなのにサーバが2台刺さっている状況が作れるのかも。
ま、Atomマシンなら、電源が200Wくらいあれば十分そうだし、3.5インチドライブ1個の代わりに、2.5インチドライブを2つ搭載して、RAIDってのも実現できそうだし。用途は慎重に選択する必要があるのかもしれないけれど、サーバを安く構築できそうで、なかなか悪くないような気がする。
…なんとなく意外な組み合わせだなぁと。
でも、実際に店舗を持っているビジネス界隈では存在感のあるTポイントも、ネット界隈だとさっぱり存在感を感じなかったりするのは私だけだろうか。ネットにどっぷり感のある私からすれば、Tポイントより、むしろ楽天ポイントの方が身近な気がする(汗)まぁ、もしかすると、CCCはその辺をなんとかしたかったりするんだろうか。
…とはいえ。
価格.comも、当初はパソコン中心だったけれど、今ではいろんなモノを取り扱うようになっているが、やっぱりモノを売っているサイトではない。そうなると、ポイントとの距離感は近くないような気がする。それに、既存のTポイントの会員をネットに誘導する(＝IDをひもづける)のも、ビックカメラやヨドバシカメラががんばっているのを見ていると容易ではないんだろうなぁと思う(Tカードを持ってないので詳しくはわからないんだけど、今ではTカードを作れば、ネットでのID/PASSもセットで発行されるんだろうか)単に、Tポイントの企業のプロモーションを価格.comでやるっていうのなら、資本提携するほどのことでもなさげだし。
ふと、デジタルガレージの決算短信をぼーっと眺めてみると、子会社のテクノラティジャパンなどの業績不振に伴う資産価値の減損処理と、株式の評価損による特別損失を抱えているみたいだったけど…(汗)その辺も関係あるんだろうか。
参考：
デジタルガレージ「平成21年6月期 第3四半期決算短信」：
gangliaでサーバを監視させようとしたら、gmond.confで監視対象とするmetricを設定するというところまでは、わかったんだけど、CPU関連の「cpu_aidle」と「cpu_idle」ってなんだろうというのがよくわからず。
…似たような名前で、遊んでるマシンを監視対象とした場合、(ぱっと見た感じ)似たような値を出力してくれてるので、どっちかでいいかなぁと思ったりして。
で、Google先生に聞いても教えてくれないので、gangliaのソースを解凍して、./gmond/modules/cpu辺りのmod_cpu.cをなんとなく眺めてみたら、それっぽい配列があった。
static Ganglia_25metric cpu_metric_info[] = { {0, "cpu_num", 1200, GANGLIA_VALUE_UNSIGNED_SHORT, "CPUs", "zero", "%hu", UDP_HEADER_SIZE+8, "Total number of CPUs"}, {0, "cpu_speed", 1200, GANGLIA_VALUE_UNSIGNED_INT, "MHz", "zero", "%u", UDP_HEADER_SIZE+8, "CPU Speed in terms of MHz"}, {0, "cpu_user", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the user level"}, {0, "cpu_nice", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the user level with nice priority"}, {0, "cpu_system", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the system level"}, {0, "cpu_idle", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request"}, {0, "cpu_aidle", 3800, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "Percent of time since boot idle CPU"}, {0, "cpu_wio", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request"}, {0, "cpu_intr", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "cpu_intr"}, {0, "cpu_sintr", 90, GANGLIA_VALUE_FLOAT, "%", "both", "%.1f", UDP_HEADER_SIZE+8, "cpu_sintr"}, {0, NULL} };
これによると、
cpu_idle: Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request
cpu_aidle: Percent of time since boot idle CPU
ってことのようだ。
後者の「cpu_aidle」がbootしてからの経過時間に対して、CPUがなんにもしてなかった時間の割合、前者の
「cpu_idle」はCPUがなんにもしてなかった時間-(ディスクIOを待っていた時間)の割合ってことだろうか。
…ただ、グラフを眺める限りでは、「cpu_idle」は、bootからの経過時間で計算って感じではなさそうなので、なにか単位時間に対して、値を計算しているような気がする。
「cpu_aidle」の値を、長い期間、監視しつづければ、CPUが使われることによって値が低下してくことになるだろうから、サーバリソースの追加投入時期の検討なんかに使えそうな気がする。
一方、いつ、CPUにどれくらいの負荷がかかったかは「cpu_user」とか「cpu_system」で取得できそうな気がするので、「cpu_idle」はCPU負荷の監視項目としては要らない気がするなぁ…。うーむ(汗)とはいえ、CPU空き率(?)を見ようと思ったら、「cpu_user」と「cpu_system」などを足し算して、100から引くみたいなことをせざるを得ないので、それはそれであってもいいかなという気もしてみたり。
…とはいえ、古めのPC(NorthwoodなCeleron機…涙)にCentOSを入れて、Gangliaでグラフを書かせてみたら、グラフを書く負荷で、そのマシンの負荷が閾値を超えたりする始末なので、とりあえず何でもかんでもグラフを書きやがれってのも、多少、危ないかなという気もするし…と。
© 2025 ただのにっき。
Theme by Anders Noren — 上へ ↑