やー忙しい。
頭があとふたつ、手はあと6本くらい欲しいです。

ユーザー様よりいただいた、要望・クレーム等々を加味いたしまして、新しいあやぽんRSS!の機能（予定）としては以下のようなカンジになります。

カスタマイズ機能を大幅強化
HTMLの分からないひとも、分かるひとも、問題なくご利用いただけるよう、カスタマイズ項目をがーっと増やしてます。
けっこうお問い合わせメール見てると、「なんかブログに貼ると真ん中寄せになるんでどうやったら左寄せになるの？」とか「文字を小さくするにはどうしたらいいですか」とか「表示領域をスクロールさせたいんですが」とか、けっこうありますんでね。
そのへんもあやぽんRSS!内で設定できるよう対応したいですね。

あとけっこう多いのが新しいエントリーには「new!」マーク出したい、ていうのですが、こちらも時間指定でできるよう対応します。
文字でも画像でもイケるようになる予定。

他にもデフォルトアイコン画像も小さいマーク風のやつ増やしたり、またはアイコン画像なしにしたり、アイコンを文字に変えたり、その他もろもろです。

DrecomRSSでやってるカテゴリごとに分けて表示、とか日付ごとに分けて表示、とかそのへんどうしようかなぁと考え中です。
あんまし要望がないので後回しにするかもしれません。

管理画面デザイン一新
お問い合わせ、もしくはクレームでもっとも多いのが、「○○をしたいがそれがどこにあるのか分からない」っていうヤツです。
もぉーほんとわかりにくくてすみません。（ユーザー様の中にはご自分のサイト内で解説していただいてる方もありますが、ありがたいことです。）

このへんも大分改善される予定です。
あと、ヘルプも充実させ、要所要所でヘルプが参照できるようになります。

・・・けどそれはそれで、やっぱりわかりにくくなった！ていうクレームくるかなぁ。('A`)

RSS設置コードの確認
次に問い合わせで多いのが、「RSSが更新されない」ていうもの。
ユーザー様にはめんどくさい仕様なのですが、ウチのは設置コードを正確に貼ってないと、RSSの更新がストップする仕組みなんですよね。
どうも説明不足らしく、ご不便をおかけしてます。
ということで少なくとも、きちんと設置できているのかどうかその場で確認できるようになります。
また、設置できていない場合は、原因と思われる箇所を提示いたしますんで、それをご参考ください。

ひとつのフィードから複数エントリーを表示
現状ではひとつのRSSフィードから最新の1件しか表示されないわけですが、これを10件まで増やそうと思います。
フィードごとに最新の何件まで表示するか決められるようになります。
これもけっこう要望が多かったので。

キャプチャー画像はオンマウスで読み込み
えーまぁ、これは完全にこちらの都合の話しなんですが、キャプチャー画像も弊社サーバーにおいて表示させてるもんだから、サーバ負荷がハンパないんです。いくらサーバ増やしても苦しい。('A`)
今は最初から読み込んで、オンマウスで表示状態にしてますが、ちょっとこれはもうやめよう、ということで・・・。
あのーその代わり、表示にあたっては若干オサレになる予定ですんで・・・、ええ、ひとつよろしくどうぞです。

RSS更新頻度の改善
今はあんましRSSの更新頻度がよろしくない（1時間～）ので、これを改善すべくｺﾞﾆｮｺﾞﾆｮ・・・。
データ構造とか一新するので、それで大分速くなるかもｺﾞﾆｮｺﾞﾆｮ・・・。
しっかし、Google Readerとかこのへんどうやってんのかなぁー！！

・・・他にも細々ありますが、大きな点はだいたいこんな感じです。
PING受付とかも要望は何件かあったので、どうしようかなぁーと思ってるんですが、RSSの更新が早くなったらあんまり必要ないかな、とも思ってます。
どうもPINGの仕様ってよくわからんのですよねー。みんなバラバラの形式みたいだし。

なんか他にご要望・提案等ありましたら、ここのブログのコメ欄でも、お問い合わせから送っていただいても、どっちでも良いので、ｼﾞｬﾝｼﾞｬﾝﾊﾞﾘﾊﾞﾘ送ってくださいね。
お待ちしてまーす。

リニューアルオープン予定としては、ちょっといつになるか分かりませんが、4月か5月くらいを目指してます。
登録のアフィリエイトとかをやる予定もﾁﾗﾎﾗとありますんで、よろしくです！(｀･ω･´)ゞ

で、まぁ今世界でデファクトになりつつあるブログ系CMSのWordPressのカンファレンス？みたいのが福岡であるらしいと聞きまして。
ぼくは自分でデザインもHTMLもプログラムもできるので、「全部自動でできますよ！」とか言われてもねぇ。自分でできるしｲﾗﾈｪ・・・ってことで、そこまで興味はなかったですが、誘われたので行ってｷﾏｼﾀ。

そもそもCMSも5年くらい前はたいしたのがなかったんすよねー。
非ブログ系のMambo、Nucleus、Xoops。
ブログ系ならMTくらいしか名前は聞かなかったですね。

その後、ずいぶんCMSはTYPE3とかMambo派生のJoomlaとかいろいろ出ましたが、もっとも勢いがあったのが、海外でMT勢をあっという間に駆逐したWordPress。
日本でもMTをどんどん駆逐していって、すでに逆転してるのではないですか。
やはりMTは検索CGIなんかが動くとものすご重たいですから、サーバ屋さん泣かせですもんね。

会場はこんなカンジ。
公演内容は割りとおもしろかったですよ。
外国人のひとも数名いたし、日本の有名なプラグイン作者のひとなんかもいて、なかなか豪華。

なんと朝の10:00～18:00までかなりの長時間セミナー。
もうぼくは途中で疲れてしまって、かなり居眠りしちゃいました。
多くのひとはアノ後懇親会とか行ったんだそうで、みんなタフですﾅｧ。

セミナー聞いてて思ったんですが、WordPressちゅーのは、なかなか手軽にサイトorブログが構築できるんだそうで、テンプレートにはPHPから（WPの）コア関数を呼び出してるだけっぽいので、いちいちテンプレートの制御構造やら変数やら覚えなくてすむのがデカイです。
また、コミュニティはまだ熟成不足と感じますけど、それでも数千、数万のプラグインとテーマがすでに登録されているので、

* デザインしかできない
* プログラムしかできない
* または両方できない

ってひとにはなかなか便利なシステムなのではないかと感じﾏｽﾀ。
もちろんこういうコンセプトはMTほか、CMSはみんなそうなんでしょうけど、WPはいっそうお手軽といった感じですんで、初心者の方にはけっこうおすすめかなー。

また、基本は動的生成なので、MTみたいな再構築が必要ないのもステキ。
そして動的生成によるサーバの負荷をおさえるためにキャッシュ機能もプラグインで提供されてます。

DBはMySQLしか選択できないらしいので、将来的にSQLightとか単体ファイルタイプの簡易DBにも対応できれば、レンタルサーバを中心にしてもっと普及する可能性もあるなぁ。
WP3.0からはマルチユーザー版と統合されるということで、今後もっと注目されそうです。

これに対して危機感を持ってるであろうMT勢はどう巻き返していくのか注目ですね。
MTの強みは宣伝力だと思うので、ブランドイメージでうまいこと、こう・・・わかんないですけど、お互い競いあって欲しいモノです。

てことで、今回はせっかく聞きに行ったので、ささやかなWordPress布教活動の巻、でした。
SixApartのパートナー企業で名前だけ載ってるのに、こんなん書いて大丈夫なんだろうか・・・。(笑)

まーこの「黄金虫」という小説は、頭の良いおっさんが、キャプテン・キッドの財宝を記した暗号が書かれた羊皮紙を偶然見つけて、暗号を解読し、お宝を発見するストーリーです。
肝心の暗号解読の部分は、「おやおや、君は暗号の話しですっかり退屈してしまったようだねえ」とそれ以降の謎解きを省略してしまうので、実につまらない。
ぼくは頑張って省略された部分もちゃんと解読してみました。懐かしい。

さて。
暗号というのは、この情報社会ではなくてはならないものになりました。
無線通信のWEPもそうだし、ターミナルでサーバに命令するときのSSHもそう、ショッピングなんかするときのSSLもそうですね。

銀行その他で、パスワードをデータベースに含める場合も、平文のまま保存することはまずなく、単一方向に暗号化して保存します。
照会するときは、ユーザーの入力を同様にして単一方向で暗号化し、すでに暗号化されたパスワードと見比べる、というのは最低限、どこでもやってます。
だから管理者もユーザーのパスワードがわからないようになってますね。

しかし。
この単一方向暗号化は、元の平文が割れにくいという点ではいいんですが、やはり複号して平文をゲットしたい局面も多々あるものです。
もちろん複号できる暗号化のルーチンもたくさんある（3DESとかPGPとか、複数鍵方式のRSAとか）のですが、そこまでおおげさなことせんでも、ちょっとわかりにくくしたい、というだけなら、太古の昔より洗練されてきた暗号法をちょっぴり応用するだけで、どんな処理系でもできます。
PHPの場合だと、PEAR::BlowfishとかMcryptとか別途モジュールを導入しないといけないので、めんどくさいですしね。

というわけで。
今回はPHPで文字列を簡単暗号化してみようという、たまには技術的な内容でお送りする企画です。

平文：

・・・というシェイクスピアの「お気に召すまま」のセリフを暗号化します。

まずこれを mb_convert_encoding() でEUC-JPに変換→base64encode()でエンコードします。
なんでEUCにするのかというと、UTF-8のままだと以前うまく動かなかったんですよねぇ・・・？
base64エンコードは、PHPはデフォで使えますが、使えない処理系でも、RFC-2045だかなんだかで定義されてるので探せばライブラリが必ずあります。

でまぁ、これをエンコードした結果はこれ。（１）
長いので改行してますが、1行です。

次にこれを1文字づつASCIIコードに変換して3桁ゼロスタンプします。
PHPの場合は一文字づつ ord() してください。

（２）

次に暗号化の鍵を決めます。適当な文字列で。

暗号鍵：

これも同様に base64encode() →（１）と同じ長さになるように繰り返して連結→1バイトづつ ord() します。

（３）

次に（２）の数字と（３）の数字を一桁づつ足していきます。
その際に10を超える場合は、10引いてください。
要するに、2+3は5のままでいいですが、7+8は15でなく5と計算してください。
そうすると桁数は（２）または（３）と全く同じ別の数字が出てきます。

（４）

次にこれを今度は3桁づつ取り出し、chr()を使って、ASCIIコードから通常の文字列に変換。
なんか変なバイナリデータになりますが、だいじょーぶ！（PHPの場合は）
これを再びbase64encode()します。

暗号文：

はい、これで暗号化ができました！

複号する時はこれを逆に辿るだけで良いので簡単です。
まず、暗号文を base64decode() →1バイトづつ ord() します。

（５）

これが、（４）と同じものにならないときはどっか間違えてます。デバッグ、デバッグぅ。(笑)
次に暗号鍵から、長さを揃えて、（３）と同じ数字をもっかい作ってください。

（３）再掲

次に！
再びこの（５）と（３）を1桁づつ計算するわけですが、今度は足すのではなく引いてください。
当然さっきとは逆で、マイナスになる場合は10足してください。

（６）

これが（２）と同じになってない場合は、やはりどっか間違えてます。デバッグ、デバ（ｒｙ

次にこれを3桁づつ chr() → base64decode() → mb_convert_encoding() でEUC-JPから元の文字コードに変換します。

（７）

元の平文がゲットできましたかー？
できた方、おめでとうございます！
後はこれを基本として、間に複雑な文字列変換処理を入れれば、その暗号ルーチンはどんどん強化されていきます。
できてない方はデバッグ、デバ（ｒｙ

最後に、こういう簡易暗号化の良い点と悪い点についても述べておきます。

良い点：
* 安全度の高い3DESとか使うよりは処理が速い。(･∀･)
* PHP以外の処理系にも十分応用が効く。(･∀･)
* ショボイとは言え独自ルーチンなためパスワード総当りアタックにも強い。(･∀･)
* お望みとあらば画像だってなんだって、base64エンコードできるものならなんでも暗号化できます。(･∀･)

悪い点：
* なにしろショボイのですぐ解読される恐れも十分ある。('A`)
そもそも、最後の暗号文を見ればbase64エンコードしてるのがバレバレである点。(´；ω；`)

従って使いどころとしては、万が一のデータ流出の際、被害拡大を防ぐため、個人情報を一部簡易暗号化するとか。
クッキーに生データ突っ込みたくない場合とか。

・・・そんなときにくらいしかないですけどねー。(笑)
もうだいぶん長くなったので、実際のコードまで載せないですけど、ご要望があれば次のエントリーにでも。
ではでは。

さて。
iPhoneもそうなんですが、こないだ発売されたiPadもやっぱりFLASH未対応なんだそうで、Adobeが大変な危機感を持ってるようす。

アドビ、「iPad」の「Flash」非対応に苦言

これに対してAppleの言い分。

「Appleはいずれ市場の圧力に屈する」　AdobeがFlashめぐりコメント

うむ。
そのうち「お前のかーちゃんデベソ！」とか言い出さないといいですが。

AppleがFLASHに対応しないのは、現在iPodやiPhone向けのサードパーティ製アプリ販売してる「App Store」で自社のモバイル機器の商品流通を独占したい、という戦略があるんでしょうから、当然。
アプリのラインナップは玉石混交でも、なかにはわりと便利なもんもあるようですし、ユーザーも「FLASHが使えないのは不便だ！」とぶーぶー文句言いつつも、やはり売れてますからね。
こうした姿勢はユーザーの利便性を損なってるんでしょうけど、Appleには昔から常に一定数の信者がいますから。
彼ら／彼女らの布教活動の成果もあるんじゃないかと思います。

というわけで。
Apple信者でもAdobe信者でもないこのYTが、というよりそもそもスマートフォン市場にあまり興味のないYTが(笑)、公平な立場から今回の件についていささか私見を述べてみたいと思います。

1) FLASHについて

まぁこのー、FLASHというものは、良い点もたくさんあるが、悪い点もやたらと多い仕組みですよね。
良い点は

* とにかくインタラクティブであることと、
* それが簡単に製作できること、
* 機能の割にファイルサイズが小さいこと、
* ほとんどのPC、モバイル機器に普及してるということ、
* 自由度の上がってきたスクリプト環境があること。

これらはさらに拡大の方向にあるようで、電化製品なんかに組み込む「Open Screen Project」というのもあるんだそうです。
また、WEB製作会社が単価を上げるためのセコイ手段としても、一役買ってるていうのもありますね。

すでにたくさんのFLASHで作られたインタラクティブ・コンテンツが世に溢れてるわけで、ユーザーとしては、こっちも利用したいところではあるでしょう。

悪い点はとにかく重いこと！CPUのパワー喰いすぎ！
ただでさえ重たいFLASHの上でさらに動画でもストリーミングされた日にゃーうちのPCが火を噴くぜ！・・・ていうとこですねぇ。
モバイル機器はバッテリ駆動時間が重要ですが、（信者はそこは絶対言わないけど）Apple製品はここが実に弱いですから。
バッテリ駆動時間が短すぎるApple製品に、CPUのパワー喰いすぎるFLASHを載せられれない！という理由もあるんじゃないすかね。
その上、FLASHクリエイターのUIデザインは8割方質が悪いので、操作しにくいという問題も付随的にあるわけで、カクカクと重い上に、クリックできる場所が小さいとか・・・なんの罰ゲームだよ、と思います。
おまけに音はうるさいし、やたらと飛び出してくるしウゼェェェェ！・・・ってこれは製作側の問題なのでこのへんで。
ただし、FLASH PlayerについてはAdobeも思うところがあるようで、近々リリースされるPlayerはソースコードを大幅改変して軽量化をはかるというウワサがあります。（はいはいﾜﾛｽﾜﾛｽで

あともう一点は、Adobeはセキュリティにかんしてワキが甘すぎるという不安。
Adobe Updateの脆弱性を突かれてガンブラーウイルスに感染・・・ていう事件もありましたね。リンクは貼らないけど。

2) HTML5について

まぁそんなこんなで、FLASHをソデにしたいAppleが積極的に導入していくと思われるHTML5です。
あんまり詳しく知らないんですが、インタラクティブコンテンツもHTML内で定義できるんだそうですね。
Youtubeでも一部動画はHTML5で配信されてるものもあり、脱FLASH依存の流れは密やかに進行中。

しかし。
現段階で言えばMicrosoftがこの流れにまったくﾉﾘﾉﾘでないのが大問題。
日本に限って言えば、8割のユーザーがIE6、7、8のどれかを使ってるわけですが、どれもHTML5、CSS3にはほとんど対応できてない。
日本のユーザーを相手に商売してる我々からすると、世界の流れがどうあれ、IEで見られないコンテンツ作成（手段）については検討の余地があまりないのです。
頼むよゲイツくん。

それにアレですよ。
以前HTMLでガチャガチャやりすぎて本来の目的（文書の構造化）から逸脱しすぎちゃったよｴﾍﾍっつて、それらを分離しようとどえらい苦労を強いてきたくせに、また同じことやってどーする。
テーブルレイアウトからCSSレイアウトに移行するときの悪夢再び・・・にならないように策定してって欲しいですね。

3) Appleの立場で見ると・・・

ぼくが普通にブラウジングしてる限りでは、FLASHが原因でブラウザが落ちたり、OSが落ちたりしたことは皆無に近いので、「バグだらけじゃんｗｗｗ」ていうのはちょっと言いがかりじゃねー？と思っていたのですが、ネットでいろいろ見る限りそうでもないようです。
どうもMAC用のFLASH Playerがいろいろとイマイチなできらしいですね。
MAC使わないのでよくわかんないですが、たしかにぼくの彼女（ﾏｶｰ）はFLASHを常にOFFにしてるよなぁーと今思い出しました。

Appleからすれば、Adobeが提供するFLASH Playerには怒り心頭なんでしょーね。
気持ちはよく分かります。
（分かりますが、ユーザーからするとどっちが原因か、なんてどーでも良い話しです）

4) Adobeの立場で見ると・・・

今回のAdobeの最大の強みは「ユーザーの利便性を代弁している！」という錦の御旗がある点です。
なんといってもAppleが自分の都合でユーザーの選択肢を奪いやがってけしからん！というひともたくさんいるんでしょうし、そのへんでうまいことネット世論を誘導できればあるいは。

でも無事にFLASH対応になったとしても、Adobeの旨みはそんな多くなさそうですけどねー。
有料FLASHコンテンツを配信するたびAdobeにロイヤリティが入るわけでもなし、見通しは悪い。

Adobeの製品はとにかくなんでもかんでもクソ重たいですから、そのへんもクリアする必要があり、なかなか今までの流れを見る限り無理そう。
Macromediaを吸収してからのAdobeは特にひどく、元々そういうのが苦手なんだろうなぁとは思います。
まぁ殿様にならないように頑張って欲しいですけどね。

5) というわけで結論

今回の件はAdobeにがんばってほしいけど、AppleからするとAdobeの言いなりになる必然的な理由がないため、すぐにどうこう、というわけにはいかなさそう！
だってFLASH対応しなくても売れちゃってるわけですよ、これは強い。
iPadはでかいので、さすがにFLASH非対応で文句も増えるかもしれないですけど、売れてるうちはAppleも知らん顔でしょう。
ていうかぼくがジョブズなら絶対知らん顔するし。

スマートフォン市場でiPhoneやiPodに対抗できるようなのが現れれば、そしてそれがFLASH完全対応なら、また話しはわからなくなりますけどね。
まぁAndroid頑張れ、としか・・・。('A`)

とりあえずまとめはこちら。→プログラミング基礎文法最速マスターまとめCommentsAdd Star
ほんと言語ってやつは、汎用的なもんから専門的なもんまでいろいろありますね。

してこの世には「Brainf*ck」なる言語もあるんですが、ご存知ない方がほとんどと思いますので簡単にご紹介。（ぼくも最近知った）

Wikipediaによると：

ということで命令系統が8つしかなく、制御構造といえばジャンプだけ。
これを利用して、様々な（難解な）プログラミング言語を作ることができるんだそうで、JOJO言語というのを作ったひとがいるっぽい。
（JOJOの奇妙な冒険についてはこちらを参照）

ｗｗｗｗｗｗｗｗｗ
カオスな全文は上記リンクよりどうぞ。

これおもしろいですねぇー。
JOJO言語の命令系統は以下の8つ。

わかりづらっ！
この調子でガンダム言語とか北斗の拳言語とか作れちゃうわけですね。

というわけで、今回は時間がないので、JOJO好きでない方にはまったく面白みのないネタ紹介でした。

いろんな意味で相撲界に注目を集める力士でしたけれども。
人気があったことも事実で、昨年の好きな現役力士ランキングで４位という結果は、
人気の力士だったことを物語っている気がします。

相撲の世界は古くて、ものすごく伝統意識が強い世界なんだと思うんですが、
強い力士を土俵にあげるために外国人力士を育てて、強い朝青龍が誕生したわけですが、
最後まで日本のしきたりに馴染めなかったのかもしれませんねぇ。
何の世界でも伝統文化と新しいものの融合というのは本当に難しいものだと思います。

大リーガーのイチローやサッカーの中村俊輔は、世界の舞台で活躍する実力をもってプレイしていると思いますし、昨年のワールドベースボールクラシックでは日本が世界の頂点を極めたわけですからね。

相撲の力士の場合、日本人と外国人と比べると、体格差や筋力差が大きく左右しているんだと思います。
外国人力士の近年の活躍を見ると、そう思わざるを得ないわけです。

しかしながら、他のスポーツでも活躍している日本人がいる限り、相撲界でも再び日本人横綱が活躍してくれる日がくると思います。
いや、必ずきて欲しいという気持ちになります。

同じく日本のスポーツといえる柔道では、日本人が外国人選手相手に十分戦えているわけですしね。

相撲界の組織の成り立ちや、上下関係云々っていうのもあるとは思いますが。
もっと日本人の子供たちが純粋に憧れる力士がたくさんいい姿を見せてくれるようになれば
将来、大相撲に多くの日本の力士が育ち、もっと日本人が誇れる日本のスポーツ大相撲になると思うんですけどねぇ。

こないだAppleが、AmazonのKINDLEに対抗して、iPadというやつを発表しましたが、早速こういう画像が出回ってる。
ぼくは正直言うと、このジョブズがニヤけ顔で持ってるiPadをみても「でけぇー！こんなん誰が買うんだ」と、ビタ一文欲しいとも思わなかったんですが・・・。

New Apple iPad (HD) 720p

動画見るとちょっとヤバイですね。欲しい・・・ｶｺｲｲ・・・(笑)
ほんと、Appleは商品のプレゼンということに関してはウマイと言わざるを得ない。

いいですね、この流れ。
紙のもつ情緒も捨てがたいけど、やっぱり音楽もデータにするのがいまや一般的ですから、書籍もこうなるのが自然。
第一、ハードウェアにすると、製造だの流通だの様々なコストがかかるわけですから、データにして直接ユーザーに配信するほうがデベロッパーも儲かりそう。
ゲームなんかも、今はSteamなんかを初めとしてダウンロード販売が急速に進んでいますし、これが時代の流れなんですね。

キンドル「印税70％」の衝撃 不況の出版界には大脅威

印税70%はすごい。インパクトを狙ってのことでしょうけど太っ腹ですねAmazon。
しかしこれは、著作者は自分の著作物に対して、自分で責任を持つということも意味すると思うのですが・・・。

さて。
技術革新が起きると困るのが、旧来のビジネスモデルで食ってる業界です。

iPadで拡大する日米の情報格差

日本はこの流れに対抗して、「抜け駆け禁止！」という情けないことになってます。

大手出版21社、電子書籍の業界団体を設立

コレを見て「さすが日本！対応が早いぜ！」と思うひとは皆無なわけで。
新規参入は絶対排除しよう、おれたちの既得権益を守ろう、著作者にいい顔させるな、ユーザーからできるかぎり搾り取ろう、という意図が見え隠れします。
まぁ好きにしたら。（鼻くそほじりながら

そして極め付けがこれ！

日販総量規制の噂の何が問題なのか？～佐々木俊尚氏が解説～

日販が総量規制するのがホントかどうか知りませんが、本屋さんの流通というのはそういう仕組みになってたんですねー。
自転車操業やないか・・・。

電子書籍が主流になるとこのへんの業界とかどーするんだろうか。
ただでさえ、インターネットに客取られて、雑誌とか廃刊の嵐なんですが。

それにしても、こんなふうに様々な業界で、ありとあらゆるコストの最適化が図られる時代になってきたんですねぇ。
いろいろと感慨深いモノがあります。
「商品を直接あなたへ！」みたいな感じで、中間搾取的な位置にいる業界は、不景気に加えてさらに苦しいことになりそう。

さぁどうなりますやら。

まぁあの、現在じーさん、ばーさんが増えすぎて社会保障費がバカにならんということで、定年を70歳にしようとか、消費税を10%～15%くらいまで引き上げようとか、いろいろ話しに聞きますね。
今の税収に占める歳出の割合を見ると、公務員の人件費がかなりの割合を占めるんだそうで、ここのブログによると、

ウソかホントか知りませんけど、まじっすか・・・という気分になるわけで。
そりゃそんな人件費遣ってたら、予算足りないわなぁ。
消費税が上がるのは日本人の大半が「しょーがねぇ・・・」と諦めてるとは思いますが、この不景気に税金上げたらリアルに死者が増えそう。
先に公務員の給料下げるか、人を減らすかしないとマズイんじゃねーの？と素人ながら思います。

でも定年70歳とかそういうのは困るんです！

実はぼくらのぎょーかいには将来確実に起こりうる非常に困った問題がいくつかありますが、技術者の間でもっぱらささやかれるのが、

１）UNIXタイムスタンプの2038年問題
２）IPV4アドレス枯渇問題

です。（他にあるかな？あまり詳しくないので・・・）
２の方は緊急度が高い、というか残り10%を切ったとか言われてるので、これは大変な関心を持ってニュースを追いかけるのですが、１の問題はそこまで真剣に考えてなかったんですよね。

だって2038年にはぼく64歳だもんなぁー？
もう定年退職じじいだし、しらねーってwww
若い世代の開発者が頑張って直してねｗｗｗ

・・・と思っていた時期がわたしにもありました、みたいな・・・。
日本中がてんやわんやになってる時に、縁側でヨーカンでも食いながらのんびりしてる予定なのに、定年が70歳になったらマズイじゃん！

っていうかここまで書いて気がついたのですが、70歳になっても働かなきゃならんのですねぇ。
会社の定年時期は早くなる一方、国の年金支給時期は遅くなる一方。
ぼくらがジジババになるころには、定年退職40歳、年金支給開始80歳とかなってそう。なんの罰ゲームだそりゃ。

28年後・・・。
霞む目をショボショボさせながら、震える手でキーボード叩いて2038年問題を修正してる老プログラマーを見かけたら、それはぼくかもしれないので、優しくしてくださいね、若い諸君。(´；ω；`)

・・・いや自分でまいた種だろ・・・orz

「戦闘力たったの5か・・・ゴミめ・・・」

なーんて言われちゃったりするわけです。
ぼくは常々これの技術力版があったらイヤだなーと思ってるんです。

「技術力たったの5か・・・ゴミめ・・・」

とか言われたらもう立ち直れないYT@ゼロファクトリーです。('A`)

さて。
@ITにこんなコラムがあったんだそうです。

技術立国への復活: 「なぜ、IT技術者が人気職種でなくなったのか？」

ああー・・・。
痛いトコ突きますなぁ。('A`)
この技術力の定量化っていう問題は、なかなか底が深いというか、難しいですね。

１）開発作業の平準化
こういう処理は○○さんじゃなきゃこなせないよねー、という状態は企業にとって非常によろしくないのです。
○○さんも、そうでないひとも、人間が1日に与えられる時間は等しく24時間ですから。
第一、〇〇さんが交通事故で入院したら「こういう処理」が誰もできない、では困る。
なんとかして、すべての工程を「まぁ誰でもどうにかこなせる」というレベルにフォーマット化しなくてはならないわけです。

そうするとどうなるか。
「あたしが死んでも代わりはいるもの」じゃないですけど、プログラマー諸氏の労働価値がどんどん下がっていき、当然単価も下がる。買い叩かれて労働時間も増える。
フォーマット化された内容以上の成果を出しても「余計なことすんな」とばかりに否定されれば、そりゃやる気が失せるってもの。
日本のIT企業がイマイチ、欧米に比べて盛り上がってないのは、このへんが原因かと思います。
こういう没個性化現象はいかにも日本人的ですね。（悪い意味で

２）ゼネコン体質化
日本でITが盛り上がってた当初から実はこの問題はあったんです。
個人事業主レベルでも「いかにして楽してナカヌキをやって逃げ切るか」ばっかり考えてるひと多かったですもんねー。
企業なら推して知るべし、です。
現在でもこれは変わってないでしょう。

大手SI屋が政府や大企業から億単位で受注→2次請け、3次請け・・・と間を抜かれていき→数百万規模の案件になって最後の受注者が泣く泣く開発→プログラマーKAROUSHI

・・・ほんともぉーハゲタカみたいなのがどこにでもいますからね！
喰うか喰われるか、みたいな殺伐とした雰囲気がいいんじゃねーか・・・って全然よかぁない。
こういうのがなきゃ、日本のITぎょーかいで働く諸兄も、「ITドカタ」なんて言われずにすんだのになぁ。
「お客さん」が直接見えない仕事ちゅーのは、やっててもつまらんと思うんですがねぇ？

日本には古来より腕の良い職人を大事にしよう、敬意を払おう、という習慣があるにも拘わらず、この状態はいったいなんなんですか。
もぉーほんともどかしい。
PMにせよ、PLにせよ、SEにせよ、全部プログラマーができることじゃん。
それをわざわざ上流だの下流だのに分けたり、人月いくらいくらとかいう風潮はいかにもナンセンスだと思うんですが、他のプログラマー諸氏はいかがですかねぇ。

ちなみに、ウチの会社は中小零細ですが、下請けで仕事することはないので、上記のようなゴタゴタはないですし、ドナドナをBGMにして売られることもないです。
まぁ基本的には実力相応に評価されるんではないですか。
その代わり、ウチの社長のワケわかんない仕様説明を苦労してシステムに仕上げるという作業があるのですが・・・(笑)

特に今年は、来年から始まる地デジ放送とオリンピックやらサッカーワールドカップやらが開催されることも相まって、
テレビの新製品が多く、近年売り出されたハイビジョンテレビに加え、
今年は大画面の３Ｄ立体テレビが新しく売り出されるそうです。
現在のところソニー「ブラビア」とパナソニック「VIERA」で売り出される予定。

流石にすぐに家で３Ｄ立体テレビが見れるというわけにはいかないかもしれませんが、
現在公開中のＳＦ映画「アバター」では最新３Ｄ技術を駆使した映像が見られます。
公開後わずか17日で世界興行収入10億ドルを突破したということもあり、
ジェームズ・キャメロン監督が長い期間をかけて製作した映画なので、
３Ｄ立体映像を十分楽しめる面白い映画なのでしょう！私はまだ観てないですが･･･(;´▽｀A``

現在のところ、３Ｄテレビがあっても全ての映像が立体的に見れるというわけではないようですが、
将来的には映像制作の環境が整えば、普通のテレビ放送も立体的に見れるようになり、
自宅で映画館以上の大迫力と映像美を体感できる日も近づいてきているわけです。

スポーツ放送が３Ｄ立体映像で見れるようになれば、
擬似的ではあっても体感できるとなるとものすごい臨場感なんでしょうねぇ！
私の場合。観戦しながらものすごく熱くなってしまいそうです！一人でもｗ

他にも、音楽ライブを３Ｄ立体映像で見れるようになれば、感動でしょうね！
私の場合。そこにいないアイドルに抱きつこうとするでしょうね！間違いなくｗ！

ますます家から出なくなりそうですが、ホント技術の発達はすごい･･･。

しかも時折テレビの映りが悪くなることがあったりすると、
おばあちゃんがテレビの側面をバンバン叩いてテレビを直すってこともしょっちゅうでしたからね。
ほぼ気合いでテレビを直す！技術を無視したそういう行為が可能な昔の人はある意味すごい！

先週くらいの話しですが、こんなニュースがありました。

人気プログラミング言語ランキング ‐ PHP、C++を抜いて3位

ほほぉぅ・・・、PHPてけっこう人気なんすかね。

ああーこれは若干言い過ぎですが、なかなかうまいですね！割とそのとおり。
たぶん人気なのはお手軽でクセがないからWEBデザイナーが「ちょっとプログラムに手を出してみるか」と、とっつきやすいのではないかと予想。
そしていつまでたっても「一人前のプログラマー」になれないのは、PHPは初心者向けの言語ではないから・・・というのは過去にこのブログで書いた記憶があります。

WEB系を目指すにしても、最初にやるのはたぶんC言語がいいような気がしますね。
ポインタとか他の言語で（表面上は）使わないまでも覚えておかないと、代入と参照の区別がつかないプログラマーになりかねん。
次にJavaかRubyでオブジェクト指向を学ぶ。
そしてPHPでWEBのセキュリティを学ぶ、と。(笑)

なにしろWEB系では、パフォーマンスを上げることと、セキュリティを重視することが重要なので、いきなりPHPやって「良いプログラマー」になれるとは到底思えない。
まぁぼくはCといっても文法くらいしか知りませんけどね。;-)

それにしてもこのランキングはなかなか興味深いというかなんというか。
「Objective C」は、たしかぼくの記憶が正しければ、昔MAC OSのコア部分はこれで書かれてた、というくらいしか重要度のなかった言語なのに、それがいきなり上位に来てるのは、iPhoneアプリがObjective Cで書かれてるからでしょうね。
今iPhoneアプリで夢をみようと様々なベンダーが頑張ってますが、なにしろ単価が安くあんまし儲かってないとか。
iPhoneというハードの普及具合に左右されるし、日本では厳しいかな。
でもなかなか魅力的なものもあり、iPhoneでラジコンヘリを操作できたり、けっこう面白い。スパイごっこができる。

そして「Delphi」がまだ、けっこう上位にあるのも意外です。
これはもとは教育言語のPascalというやつを若干改造した、Turbo Pascalを利用した、開発ツールの「Delphi」で使われてましたね。
後にTurbo PascalはObject Pascalになり、言語の名称自体も「Delphi」で統一されました。
（開発元のBorlandはもう潰れました）

海外でいまだにけっこう流行ってるのかな？
日本ではフリーソフトはこれで作ってるのも多いですけど現場で使ってるとこあるんすかね。あんま聞かない。

Delphiはコンパイルがやたらと早いので開発はし易いです。（その分最適化が適当
ただ、Pascalの文法は代入が「:=」（C系だと「=」）、比較が「=」（C系だと「==」）と演算子がちょっと変わってるので、Delphiと同時に他の言語使うといろいろ混乱します。
「4/2」が「2」ではなく「2.0」というふうに、除算の結果が必ず実数になり、「2.0+3」とか実数と整数で演算するとコンパイルエラーになり、「2.0+3.0」または「2+3」に変換しないと演算できないとか、最初はすごいびっくりしましたね。
整数の結果を得るには、謎の演算子「div」を使って「4 div 2」としなければワンステップで整数の「2」が得られないという。
いまだにこういう仕様なんだろうか。いくらなんでもstrictすぎる。

ちなみにぼくは2番目に使ったのがこの言語で、いろいろ思い出が深いです。

Google先生の「GO」もいきなり大躍進。
なかなか便利ちっくでパフォーマンスもよく、評判いいみたいです。
GoogleのサービスやAPIの利用状況いかんによっては、今後キラー言語になる可能性もなきにしもあらず、Google先生にケツの穴までささげる覚悟で習得しておくのも決して冒険ではないかなぁー？
例えば、今iPhoneアプリが流行ってるから・・・と「Objective C」を勉強してももう遅いので、これから流行りそうな言語、需要がありそうな言語を狙っていかねばなりませんからね。

もうーほんとプログラマーてやつはめんどくさいです。('A`)

でも、そんな感想をもっているのは私の周りも同じだったようで
連休って感じじゃなかったという意見をよく聞きました。

ちなみに私はレコード大賞見る暇なく実家に帰ったもんですから
年明けまでレコ大の大賞が誰になったかも知りませんでした。
私がやっとレコ大の大賞受賞がEXCIELだったのを知ったのは年が明けて２日でした（；^ω^）
やっぱり予想通りって感じですけど。嵐が出てない時点で８割はデキレースですよね～。

こんな風に年末年始を振り返っておりますが、
今年もアッと言う間に過ぎ去って行くんでしょうネ。
今年もアッと言う間に過ぎ去る前に、年の初めの目標をたててみることにしました。

いろいろとやろうと思うことはありますが、
まずは人間、他人に迷惑かけちゃいけないですよね。
言うまでもないことではありますが、昨年それができなかった。
というかヤラかしたことが多かったので、本気で心に誓う意味でこの目標を掲げようと思います。

私、親に似たのか酒癖があまりよろしくない( ﾟДﾟ)･∵. ｸﾞﾊｯ!!
コレ。私の中での本気の誓い！マジ真剣！

なので今年は記憶飛ばさない！飲んだ次の日、謝罪の電話しない！飲んで怪我しない！

ほんとに最近、悪酔いする回数が多いんですよね。
若い頃よりも飲む量が増えたとかそういうわけでもないんですが･･･。
肝臓機能が弱まってるのかなぁ･･･。
でも、飲んで吐くことはないんですよね。
ただ。最近は急に記憶が飛んだり、記憶が飛び飛びなコトが多いです。
そして、記憶にないアザが、どこかしらいろんなところに出来ている。

今年は！飲んだ次の日の自己嫌悪することがないように、
セーブして飲めるカッコイイ大人になりたいです。

ホント･･･いい加減いい大人なんだから･･･。

・・・という初夢を見たYT@ゼロファクトリーです。なぁ～～んでか？
縁起の良い夢なんですかねー。謎。

というわけでみなさん明けましておめでとうございます。
年末年始はいかがお過ごしでしたでしょうか。

↑年末にこういうコピペを2chで見て爆笑してたんですが、なかなか感じをよくつかんでる。
誰のことかは言わなくても分かりますよね？

正月早々あんましいいニュースもないですし、辛気くさくってダメです。
今の日本には寛容の成分が足りてないと思うのです。

ということで、せめて正月くらいは気分だけでもほんわかしたいやないか、という方にご紹介するのは以下の動画です。
（どっかの有名ブログで取り上げられてたんですが、元記事忘れ失礼）

156 Countries Sing Together for the Starbucks Love Project

スタバ主催で行われたアフリカのエイズ撲滅キャンペーンだかなんだかのイベントらしいんですが、同じ日、同じ時刻に、世界中でビートルズの「All You Need Is Love」を歌ったやつなんだそうです。
「One Song, One Wish, 156 countries.」というコピーの通り156カ国でやったみたいですねー、すごい。
みなさんプロ顔負け。上手。そして楽しそう。日本のもありますよ！

スタバのイベントサイトでは各国それぞれのバージョンも見られますんで、興味のある方はどーぞ。（日本はこちら）
ちなみに1個動画を投稿するとスタバから5ドル、エイズ撲滅基金へ寄付されるんだそうで、太っ腹ですね。
腕に自信のある方はいかがですか。
ぼくは音痴なんでいろいろ無理なんすけど、バックコーラスで歌っている「フリ」くらいは協力しますよ。(笑)

ではでは、ほんわかしたところで今年はちょっぴり優しくなれるといいですね。

まぁーあの、全国のプログラマーのみなさんも寒さで手がかじかんでるせいか知りませんが、先週やっちゃいましたね、セブン＆アイが。

セブンネットショッピングで情報漏えい！「勝手に決済して送りつけている」
セブン個人情報流出問題、ついに ITmediaに掲載される･･･セブン「XSS脆弱性はもう対策した（ｷﾘｯ」→即XSS脆弱性が見つかる

うひぃー、怖い。
何ヶ月も前から指摘はされてたようですが、なんで放置しちゃうかな。

こーゆーのがあるからー！
この業界にいる人間は、電子マネーとか、WEBでのクレジット決済とか怖くてできないんすよ。
だって大手が受けたシステムでも実際コーディングしてるの、5次受けの個人業者とか派遣のにーちゃん、ねーちゃんがやってるんですよ？怖くて使えん。
たいしたサービスないけどウチも気をつけなきゃ。

一般のかたにプログラマーていう職種のひとがどういうイメージで捉えられてるか知りませんけれども、こういうの見てもわかるとおり、WEB系のプログラマーていうのは非常にいい加減です。（業務系のアプリ作ってるのからWEB系に転向したひとも同様！）
ぼくが過去に実際見た、いい加減っぷりをちょっと晒していこうかと思いますので、WEBサービスを使う時は注意です、注意。

英単語が書けない・読めない

非常によく見るんですが、

* 「登録する」という意味で使われる「regist」（正しくは「register」）
* 「検索する」という意味で使われる「serch」または「sarch」（正しくは「search」）
* 「完了」という意味で使われる「complate」（正しくは「complete」）
* 「確認する」という意味で使われる「confarm」（正しくは「confirm」）

↑この4つは、プログラマー式勘違い英会話の四天王です。よく見る。（特にregist）
ちょっと辞書で調べるという手間を惜しんだために、世界に恥をさらすことになんだもん、怖いすね！ぼくも気をつけないと。

後は「delete」を平気で「ディレート」と読んだり、「denied」を「デニード」と読んだり・・・。

See also：regist という英語は無い

で、一見クリティカルな問題には発展しなさそうなこの勘違い。
だいたいこのテの間違いを平気でしてる（手間を惜しむ）プログラマーは、ほぼ例外なく以下に述べる適当さも併せ持つものです。
外から見てわかりやすく、ひとつの指針になるかと。

適当な認証

ユーザーがログインして、メンバーエリアのコンテンツに入れるってやつ、たいていのサービスにありますね。
あれもcookieのデータを追いかけていくとなかなかすごいモノもあります。

以前実際に見たやつは「login=1」とか「userid=3451」みたいなもんをcookieに渡して、値があるかないかで、ログイン状態を判別してるやつ。これが一番ひどい。
cookieに突っ込むならせめて暗号化せぇよ・・・。問題はそこではないけど・・・。
あと、ユーザー認証をするのがログインフォームのとこだけで、あとは素通りとか。
URL直接打つとメンバーエリア丸見え。今回のセブン＆アイのやつも、詳しく見てないですけどこれに似てるっぽい。

適当な入力チェック

登録画面なんかでよく見る、フォーム入力→確認画面→登録完了画面
・・・の流れですが、これの「フォーム入力→確認画面」間はバリデートを行い、「確認画面→登録完了画面」間はバリデートしない、というモノ。
確認画面中に、<input type="hidden".... とかで書いてあるvalue値を動的に書き直したら、不正な値を突っ込めてしまう。
2回同じとこを通せば済む話しなのに、なにがめんどくさいんだろうねぇ・・・。
で、これを指摘すると、「だーいじょぶっすよ。そんなことするやついませんってｗｗｗ」とか平気で言っちゃう。
怖いでしょ？「そんなことするやつ」が現れてからでは遅いんですが。

あとはよくある話しで、数字しか入力しちゃいけない箇所で数字以外も入力できるやつとか。
入力のチェックは「値が入力されているか、いないか」でしかチェックしてないとか。
（↑これは5年前に比べて大分少なくなってきた。）

延々と増え続けるデータ

オープンソースでなんでもかんでも無料になっちゃう時代ですけれども、なんで我々が廃業せずにすむのかというと、このテのプログラムにはたいてい大きな落とし穴があり、長期の運用に耐えないものがけっこう多いからです。
タダより高いものはないんですよ？（と、一応アピール）

処理を軽くするためにキャッシュファイルを使って軽減化を図る・・・みたいなとこはよく出来てるんですが、そのキャッシュファイルを定期的に掃除する機能がない、とか。
ユーザー操作をトラッキングできるように詳細なログを取る機能がある・・・しかし、そのログを定期的に削除する機能がなく、いつの間にかデータベースが肥大化する、とか。
別にオープンソースに限ったことでもないですが、よくある話しです。

このテの「長期で運用して初めて出る不具合」というのは、たいていの場合あらかじめ対処することが可能です。
本人の想像力次第、ですけどね。

・・・といういうふうに。
上記の問題点は、指摘されなきゃ一生気づかないかもしれない、ていうことです。
逆に言えばできるひとは最初からできるんです。
どうすりゃいいのかねぇ・・・。

プロジェクト単位で派遣されてるプログラマーなんかは、自分の担当箇所が終わったらあとは野となれ山となれ、でしょうから保守担当が泣くことになる、なんていうパターンは多そう。
設計ミスを指摘しても自分の仕事が増えるのはイヤでしょうしね。
だから、大手のシステムほど危険ですよ・・・。(笑)

まー偉そうに語ってるぼくだって、データベース直接操作してて、間違ってデータ丸ごと全部消しちゃったこともありますしね！
オマエいっつも他のプログラマーには「バックアップ取ってからいじれ」って言ってるじゃねーかよ、って話しですよね！
この話しを他人にするとみんな血の気が引いたような顔で「え・・・、それ・・・、どうしたの・・・？」って絶句されますしね！（数時間前のバックアップから復旧）
上に挙げた例なんかホント可愛いもんですよ！ガハハハ！

・・・要するに。
要するにですよ。
プログラマー稼業は神経太くないと務まらないっていう話しです。（はなし変わってｷﾀｰ