といっても、プラグイン入れただけですけど。
WP Social Bookmarking Lightといプラグインを使えば簡単です。
ついでにmixiチェックやらFacebook likeやら色んなタイプのやつが統合できました。
[WordPress]Twitter,Facebook,はてなブックマーク,Evernote,Instapapreに対応している神Plugin。
ブラウザからインスコできるしwordpress便利だなー。
今回の震災でtwitterは非常時の連絡手段として活躍しました。
加えて、放射能漏れに関して、雑誌や新聞、テレビなどのマスメディアに時にデマまがいの報道が見られた事もあって、情報収集の手段としても有用だと思うので。
なので先日実家に行って、両親のtwitterアカウントこさえて、パソコンとかにブックマークしてきました。
父はiPhoneとガラケーの2台持ち(！)なんで問題ないけど、母は古いガラケー。twitterは無理かと思ってたけど、フツーにiモードから登録できました。
モバツイなんて便利なモノも有るんですね。
まずはこれでよし。
後日段階的にSkypeとFacebookを仕込む予定。
事前にJDKとmeven2のインストールが必要です。
openid4javaのDownloadsから、[openid4java-full-0.9.5.593.tar.gz]をダウンロードし、C:\
にでも解凍する。
CMD.exe を起動し以下を実行。
cd c:\openid4java-full-0.9.5.593\samples\simple-openid mvn jetty:run
http://localhost:8080/simple-openid
をブラウズすると、OpenID RPのテストが出来ます。Yahoo OpenID なり mixiIDなりで試します。
OpenID プロバイダを試すには、上記URLにて、これ
http://localhost:8080/simple-openid/user.jsp
を入力します。
次回はコレを参考に、OpenID プロバイダを作ってみようと思います。
参考サイト
Java Web アプリケーションのための OpenID: 第1回 / IBM
Java Web アプリケーションのための OpenID: 第2回 / IBM
前から少し気になってた さくら Internet のVPSを使う機会がありました。いやいや、イイですね！
レンタルサーバでいいじゃん的な案件でも、独自SSL欲しいとかイロイロわがまま言い出すと数千円/月~高いので1万円前後します。それでいて、自由度が少ない。JavaServlet 動かすなんて無理。
VPSならそりゃVM(仮想サーバ)のrootが貰えるんで、ミドルウェア構築するのが苦じゃない場合はそっちの方がメリット大きいです。でも、格安VPSってパフォーマンス悪そうですね。
そんな訳で全く期待値が低い状態で、さくらのVPSを使ってみたんですが、コレがまた結構サクサクじゃないですか。手元にあるHPのML115と比較しても、Apacheとかのコンパイルが早い。下手したら半分位かも。
CentOSなんですけどどうやら64bit版らしいです。64bit版はじめてだったんですけど、多少./configure のオプションで勝手が違いますが、それ以外は特に不都合ないですね。
時間帯とかイロイロな変数が影響するんでしょうが、 サーバのスペックに加えレイテンシも含めて考慮すると素の北米の Amazon Web Services の Smallインスタンスよりもコッチの方が快適です。それでいて 980円/月 なんだから、こりゃいいな、と。
いや、嬉しい誤算です。
ついでに ｊｐドメインもさくらで取ったんですが、コレは1日強待たされましたが、DNSモドキもついて4000円強なんで、個人的にお気に入りの格安レジストラVALUE-DOMAINを使う理由が1つ減りました。
試用期間2週間は無料で使えるんで、是非お試しを。
※さくらの回し者じゃないですよ。
IaaSプロバイダはどうやってマーケットを広げるのか？ PaaSレイヤを提供するのは簡単だが、そうすると顧客にはロックインされるという懸念が持ち上がる。顧客が管理の主導権を持てるというIaaSの利点でを維持したまま、どうやってPaaSの利点である、熟練を要する運用業務を顧客から不要にする、ということを提供できるだろうか
その答えは運用を容易にするツールの提供だ。それはIaaS上に用意された、優れた（ベストプラクティスな）インフラで、可用性とスケールを実現するものだ。
これがまさにAWS Elastic BeanstalkがTomcatを用いて行ったことである。
個人的にはベンダロックインよりも、運用がどれだけ容易になるかが最大の関心事だったりする。
運用にもスケールするかどうかが含まれていると考えています。
昨今のWEBサービス開発は、php等のスクリプト言語で作るのがあたりまえです。
初期の開発者の単価が抑えられ、ホスティングサービス等を利用しやすいから。
で、幸運にもWEBサービスが流行ったら、フロントエンドのWEBアプリケーションも色々と性能改善をしつつ機能追加とかするのも大事ですけれど、ある程度の規模を超えるとストレージのレイヤ（データベース側）でがんばってスケールさせる必要が出てくる訳で、ミドルウェア含むインフラ層にもエンジニアを惜しみなく投入して、あの手この手で分散化する必要が出てきます。
最近は知りませんが少なくとも私の知る限り、php は Apache等のhttpデーモン のプロセスまたはスレッドにくっついて動く訳でして、永続的接続とかいう仕組みは有っても、アプリケーション全体でDBコネクションの数を制御したり、プーリングしたり、使いまわしたり、データベースアクセス専門のオブジェクト(DAO)をこさえて使いまわす、なんて事が簡単には出来ない訳でして、そこはもう Java Servlet の方が1階層タンデムな分そこのへんの作りこみが楽だから、ある程度の規模までならデータベースアクセスの観点からパフォーマンス面で有利だと思う訳でして、私がWEBアプリケーションとしてはマイナーな Java を選ぶ理由の1つです。
TCP/IPのコネクションを張るのはそこそこリソースを消費する訳だから、php でApacheのプロセス（スレッド）上減数に合せてコネクションを貼りっぱなし、なんて構成を最初はとったりする訳ですが、RDBMSサーバ側のリソースも結構ふんだんに用意する必要がありますし、規模が大きくなってくると、最近は安くなったとはいえスケールアップさせるのはソコソコ金がかかるんで、水平に垂直に分割したりレプリケートさせたりキャッシュしたりインフラ層でイロイロやらないといけないんで、安定させて性能を出すにはそれなりのコツというか、DBAなんていう職業が成立してしまう位イロイロな匠の技がある訳ですし、24時間365日運用するには、やはり訓練もドキュメンテーションもそれなりに必要になってきます。
で、最初の「運用がどれだけ容易になるか」の話ですが、こういう「インフラ系エンジニア」の下働きは、それなりに優秀な人材を集めなければいけないしコストがかかります。WEBサービスもマネタイズできないと単なるボランティアですからやはり収益性は大事な訳です。
誤解を恐れずに言うならば、インフラ系エンジニアは「システムの能力を最大限に引き出し（必要に応じて向上させて）たり、セキュリティ含むITをとりまくあらゆるリスクを軽減する為にイロイロとがんばる」訳ですが、それで収入が増えるとか言う事は無い、と考えられる事が多いわけです。特に経営層に。
これらはだんだんとコモディティ化してきているから、もし外注できるなら、どうせ金かけるなら優秀なソフトウェアエンジニアを中に雇いたい訳です。サービスをより良くするスピードこそ、競争力であり、収入を増やす為に必要だからです。
こういう事を書くと世の中のインフラ系のエンジニアの方を敵に回しそうなんで一応書いておきますが、価値を生むとか生まんとか以前に情報システムは運用してナンボ、作るだけじゃダメな訳で、運用管理も誰でも簡単に出来る訳じゃないです。Salesforceの様に、運用こそ差別化の最大要因だと言い切ってしまいたい所です。
さらにさまざまな問題を回避する事で、問題が発生した場合に損失しうる企業価値を損なわずにすむという面もありますんで、一概に要らないと言っている訳では無くて、AmazonやGoogleとかが、規模の原理を活かして、自社の優秀なエンジニアと運用のベストプラクティスを、IaaSやPaaSで提供しはじめている訳ですから、少なくともWEBサービスにおいては、ストレージ層も含めて「スケールする」インフラがセットで提供されはじめた今、「事業」として考えた場合、「外注」されやすい分野である事は間違いないでしょう。
要るとか要らないとか言う以前に、土俵というか、世の中のルールというかが変わって来たぞ、と。
そういう観点で、Google App Engine と AWS Elastic Beanstalk を比べると、App Engineの方が楽そうなんだよなぁ。
でも、既存システムの移行の難易度で言うと、格段にBeanstalkの方が楽そうだなぁ。
App Engineの方がスケールしそうだしなぁ。でもAWSの方が自由度高いしなぁ。
と、これからは、クラウドをコーディネートする力が求められそうですね。
纏まりなくてすいません。
