Translate

2014年10月29日水曜日

Google Book APIを使って本のサムネイル画像を表示するJavaScriptを作る

ISBNコードを元に
本の表示の画像を表示したかったので
いろいろREST APIを公開しているサービスをみてみた。

ほとんどがアカウントを作成しないと取得できないタイプだったので
半分あきらめかけていたのだけど、
Google Book API ならセキュリティキーとか作成せずにできそうだったので
ためしてみた。

Google Book APIはISBNコードをハイフン無しのコード部分だけ
数字部13桁をGETのパラメータとして渡してやれば
JSONで情報がもどってくるしくみだ。

なのでjQuery1.11.1 (IEも対応する必要があったので..) を使って
JavaScript関数をつくり、



<script type="text/javascript">
function loadBookImage(){
 var isbnCode = $("#isbn").val();
 isbnCode = isbnCode.trim().toUpperCase().replace(/[^\dX]/gi, '');
 var googleUrl ="https://www.googleapis.com/books/v1/volumes?q=" + isbnCode;
 $.ajax({
  type: "GET",
  url: googleUrl,
  dataType: "json"
 }).done(function(json){
  var thumb = json.items[0].volumeInfo.imageLinks.thumbnail;
  if(thumb){
   $("#bookImage").empty();
   $("#bookImage").prepend("<img src='" + thumb + "'/>");
  };
 });
};
</script>



bodyタグ内に
  • id値がisbnのinputタグ(onBlurにloadBookImage()を定義)
  • id値がbookImageのdivタグ
を作って試すと、簡単に表示できた。

でも、たまにISBNコードと同じでないサムネイル画像が出る..

上記関数で1件目のサムネイル画像のみ使用しているのだけど、
候補が複数帰ってくる場合もあって
それでたまに違う画像が出てくる..

そのあたりは、もうすこし jQuery のAjax に慣れてからにしようかな..

2014年10月10日金曜日

Javaで書いたWebアプリをBluemixへデプロイする




Struts2+VelocityでMVCを、
Spring Framework でDIとセキュリティを、
MyBatisでDAOを
それぞれ使ってPostgreSQL上のデータベースの入出力させる
ごくごくふつうのアプリをEclipse上で作った。

テスト環境としてローカルにTomcatとPostgreSQLを入れて
Eclipse上からテストしているが、
Bluemixをテスト環境にすればいいんじゃないかとおもい試してみた。

Bluemixサイトにログインして、
「CATALOG」タブから「Liberty for Java」を選択
名前、URL(ホスト名だけ)、選択プランを選ぶ。
でCREATEする。

そうすると作成したサーバ(?)のダッシュボードに遷移するので
「ADD A SERVICE」を選択する。
そして「Data Management」の「ElephantSQL」を選択する。
#PostgreSQLでAWSで動いているらしい

で、App欄は先ほど作成したサーバの名前をいれ、プランを選択する。
Service name欄にはプログラム内で使っているJNDI名の"jdbc/"を
除いた文字列でCREATEする。

リスタート云々言ってくるのでOKボタンを押して再起動する。

作成したデータソースをクリックし、
Launch ElephantSQL Dashboard
を押すと、
URLが表示されるのでメモる。




そしてbluemixプラグインを入れたEclipseでサーバを作成、
同一アカウントでの接続を設定しておく。
で、Webアプリプロジェクトを作成したサーバへドラッグ&ドロップすると
ダイアログがでてくるので、先ほど作成したAppsを選択すれば
デプロイ処理をしてくれる。

当然DB上にテーブルなどを作成しなくてはならないので
ローカルのpgAdmin(PostgreSQLをローカルにインストールすると
入ってくる管理コンソール)をたちあげ
コンセントマークのアイコンを押して
先ほどメモったURLを元にプロパティタブへ入力する。

例えば
postgres://hogehoge:fugafuga@foo.bar.com:5432/tar
である場合、
ホスト欄に「foo.bar.com」
Portに「5432」※もちろんproxy環境ではつながらない
データベースメンテナンス欄に「tar」
ユーザ名欄に「hogehoge」
パスワード欄に「fugafuga」
といれ(名前などは適当に入れて)「OK」ボタンを押すと接続できる。

データベース名は「tar」でこていになっているようなので
「tar」を選択して虫眼鏡アイコンを押してSQLを押し流せば良い。




本当はよくある組合せセット(boiler plate)のなかから選べばいいのだけど、
課金されることになったらをかんがえると一つ一つ必要な物だけ選んでいくのが
いいかな、とおもう。




とうぜん、tomcat-users.xmlでBASIC認証しているような場合は
アプリとしてログインを実装する必要がある。


簡単ではあるけど、SSLトンネリングとかの設定しないと
開発環境としてはめんどくさい。
なによりステップ実行できるわけではないし...

とりあえず、JNDI名で実装しとけばDBにはつながることが分かっただけでも
よしとしよう。

2014年9月9日火曜日

ISBNコードのチェックサム判定するJavaScript関数をつくってみた


ISBNをJavaScriptで扱わないといけなくなり、
チェックサム判定の関数と
ハイフン付き形式にする関数を
ISBN10とISBN13それぞれでつくってみた。
あとISBN10をISBN13にする(978を先頭につけてチェックサムを計算しなおす)関数
もつくってみた。


function isValidISBN (target) {

 var targetCode = target.trim().toUpperCase().replace(/[^\dX]/gi, '');
 if(targetCode.length == 10){
  return isValidISBN10(targetCode);
 };
 targetCode = target.trim().toUpperCase().replace(/[^\d]/gi, '');
 if(targetCode.length == 13){
  return isValidISBN13(targetCode);
 };
 return false;
};

function toISBN13(isbn10){
 var modulas = 10;
 var weight = 3;
 var targetCode = isbn10.trim().toUpperCase().replace(/[^\dX]/gi, '');
 targetCode = "978" + targetCode;
 var checkSum = 0;
 var chars = targetCode.split('');
 for (var i = 0; i &t; (chars.length-1); i++) {
  if( (i % 2) == 0 ){
   checkSum += parseInt(chars[i]);
  }else{
   checkSum += ( weight * parseInt(chars[i]) );
  };
 };
 checkSum = modulas - (checkSum % modulas);
 var isbn13 = "";
 for(var i = 0; i &t; (chars.length-1); i++){
  isbn13 = isbn13 + chars[i];
 };
 isbn13 = isbn13 + checkSum;
 return isbn13;
};

function isValidISBN13(isbn13){
 var modulas = 10;
 var weight = 3;
 var targetCode = isbn13.trim().toUpperCase().replace(/[^\d]/gi, '');
 if(targetCode.length!=13){
  return false;
 };
 var checkSum = 0;
 var chars = targetCode.split('');
 for (var i = 0; i &t; (chars.length-1); i++) {
  if( (i % 2) == 0 ){
   checkSum += parseInt(chars[i]);
  }else{
   checkSum += ( weight * parseInt(chars[i]) );
  };
 };
 checkSum = modulas - (checkSum % modulas);
 return (checkSum == (parseInt(chars[chars.length-1])));
}

function isValidISBN10(isbn10){
 var modulas = 11;
 var weight = 10;
 var targetCode = isbn10.trim().toUpperCase().replace(/[^\dX]/gi, '');
 if(targetCode.length!=10){
  return false;
 };
 var checkSum = 0;
 var chars = targetCode.split('');
 for (var i = 0; i &t; (chars.length-1); i++) {
  checkSum += ( weight * parseInt(chars[i]) );
  weight--;
 };
 checkSum = modulas - (checkSum % modulas);

 var actualCheckSum = 10;
 if(chars[chars.length-1] != "X"){
  actualCheckSum = parseInt(chars[chars.length-1]);
 }
 return (checkSum == actualCheckSum);
}

function formatISBN(target){
 if(isValidISBN10(target)){
  return formatISBN10(target);
 };
 if(isValidISBN13(target)){
  return formatISBN13(target);
 };
 return target;
};

function formatISBN13 (isbn13) {
 var chars = isbn13.toUpperCase().trim().replace(/[^\d]/gi, '').split('');
 var reformedIsbn13 = "";
 for(var i=0; i&t;chars.length; i++){
  if( i == 3 || i == 4 || i == 7|| i == 12){
   reformedIsbn13 = reformedIsbn13 + "-";
  };
  reformedIsbn13 = reformedIsbn13 + chars[i];
 };
 return reformedIsbn13;
};

function formatISBN10 (isbn10) {
 var chars = isbn10.toUpperCase().trim().replace(/[^\dX]/gi, '').split('');
 var reformedIsbn10 = "";
 for(var i=0; i&t;chars.length; i++){
  if( i == 1 || i == 5 || i == 9){
   reformedIsbn10 = reformedIsbn10 + "-";
  };
  reformedIsbn10 = reformedIsbn10 + chars[i];
 };
 return reformedIsbn10;
};


ISBN10はもうつかわれないので、
入力された場合はやはりISBN13にしてあげたほうがよいとおもい
変換する関数も作った(もとに戻す関数はつくっていない)。

やはりDBとかにはISBN13で統一して入れておいたほうが良さそうだし..

にしても..JavaScript直書きはデバッグしにくいなあ..
みんなどうやってるのかなあ..




使う場合はat your own riskでお願いします。

2014年7月28日月曜日

Vaadinの英語サイトのごく一部(Learn)を翻訳してみる

GWT.create(GWTをテーマにしたイベント、ドイツとアメリカで開催)の
ページを見ていると、Vaadinというフレームワークがよく出てくる。

どうも出自は2010年ころからでているが、日本はGWTがなぜか流行らないので情報が殆ど無い。どこぞの記事に紹介があったが3ページ目辺りで会員登録しないと見せないよっていう意地悪をされたので萎えてそのままだった。

でも、せっかくなのでイントロくらいは読んでおこうと思い、以下のページだけ翻訳してみた。

Introduction to Vaadin Development
https://vaadin.com/learn

以下私の翻訳ですが、直訳しているだけなのでとっても読みにくいです。
Yahoo翻訳よりまし程度で読んでください。
(もちろん、at your own riskで)

------

Vaadin開発へのイントロダクション


[YouTube] Vaadin Step-by-Step
https://www.youtube.com/watch?feature=player_embedded&v=KsvvF1zgMQM

この短いビデオは、Vaadin7、Vaadin Eclipse プラグイン、Apache Tomcatを使った開発のチュートリアルです。


Vaadinとは何?


Vaadinは リッチインターネットアプリケーション(RIA)のためのWebアプリケーションフレームワークです。ソリューションベースのJavaScriptライブラリやブラウザプラグインとは対照的に、Vaadinは、強力なサーバサイドプログラミングモデル、そしてGWTやHTML5ベースのクライアント再度開発ツールが特徴です。RPCやクロスブラウザ互換性、全てのレイヤをまたがったフルコントロールといった実装時の細々としたことから分離された短期開発モデルを要約します。

VaadinはUIコンポーネントの巨大な集まりです。「ボタン(http://demo.vaadin.com/sampler/#Buttons)」、「テーブル(http://demo.vaadin.com/sampler/#GridsAndTrees)」、「ツリー(http://demo.vaadin.com/sampler/#GridsAndTrees)」や「レイアウト(http://demo.vaadin.com/sampler#ComponentContainers)」といったコンポーネントからアプリケーションユーザ・インタフェイスを構築します。コンポーネントはビジネスロジックや相互にコミュニケーションをとるイベント、リスナ、データバインディングを使用します。

Vaadinは短期アプリケーション開発のための強力なアーキテクチャです。コンポーネントベースのアーキテクチャ、ならびに静的Java言語、そしてデータバインディングは、より簡単にモジュール化され必要に応じて再分解されたアプリケーション構築を支援する特徴を持ちます。「ビジュアルデザインツール(http://vaadin.com/eclipse/#visual-designer)」を含む「IDEやツール化支援(http://vaadin.com/tooling)」により、ユーザインターフェイスを高速に開発することができます。


詳細は「Vaadinの特徴(https://vaadin.com/features)」へ


Vaadinを使うと...


衝撃的なWebアプリケーション、ルックアンドフィールが違いを生む。Vaadinは素晴らしいコンポーネントや多くのカスタマイズ可能なテーマを提供します。

GWTベースのウィジェットによるブラウザ独立したウェブアプリケーション構築、Vaadinアプリケーションはリッチなユーザエクスペリエンスを提供し、かつプラグインのインストールなしですべてのモダンなブラウザをサポートします。

Vaadinを使った短期開発、数分でWebアプリケーションを作成します。数行のJavaコードだけでVaadinがのこりを世話します。複雑なXML設定なし、JavaScriptなし、RPCなし。

セキュアなWebアプリケーション、Vaadinコンポーネントを使うことで、証明されたサーバサイドアーキテクチャがアプリケーションコードをブラウザに送信しないことを保証します。

保守しやすいアプリケーション、ピュアJavaによるアプリケーション構築ががより簡単な拡張性と長期の保守性をもたらします。

オフラインかつステートレスなアプリケーション、必要に応じてブラウザ上で実行するJavaScriptへコンパイルすることで、Vaadinはクライアント側の機能をJavaで記述することを許可します。



フリーなオープンソース


VaadinはApache Software License 2.0に準拠します。これは非商用、商用プロジェクトどちらも無料であることを意味します。

ライセンスの詳細はこちら(http://vaadin.com/license


簡単なプログラミングモデル



サーバサイドJava


XML、JavaScript、ブラウザ、RPCについては忘れなさい、サーバサイドJavaコードが動作します。この分離はVaadinがGWTのようなクライアント中心のJavaフレームワークであることを示しています。

クライアントサイドJava


新たなユーザインターフェイスコンポーネントを構築するため、あるいはオフラインのアプリケーションを構築するためのHTML5、JavaScript、GWTを使用している拡張されたクライアントサイドVaadin。

コード例


 Hello World - 伝統的な例
  HelloWorld.java(http://demo.vaadin.com/docs/example-source/com/vaadin/demo/HelloWorld.java.html
  アプリの実行(http://demo.vaadin.com/HelloWorld
 Calculator - 単純なイベントハンドリング&ロジック
  Calc.java(http://demo.vaadin.com/docs/example-source/com/vaadin/demo/Calc.java.html
  アプリの実行(http://demo.vaadin.com/Calc
 Addressbook Tutorial – アノテートされたアプリの例
    vaadin.com/tutorial(https://vaadin.com/tutorial



Vaadin アーキテクチャ


どのようにしてVaadinが動作するか、そして異なるプラットフォームやほかのフレームワークと統合しているかを見てください。
https://vaadin.com/image/image_gallery?uuid=453a301a-798c-4daf-aea7-3fd115c0d88a&groupId=10187&t=1349442259604
詳細なアーキテクチャはBook of Vaadinにかかれています。

・Vaadin Introduction(https://vaadin.com/book/-/page/intro.html#intro.overview
・Application Architecure(https://vaadin.com/book/-/page/application.html)
・Communication Architecture(https://vaadin.com/book/-/page/architecture.client-side.html



ブラウザ独立


Vaadinはブラウザ互換性問題を引き離し、アプリケーションの開発に集中させてくれます。すべてのVaadinコンポーネントは以下のブラウザと互換性があります。

・Internet Explorer
・Mozilla Firefox
・Safari
・Opera
・Google Chrome


完全互換性情報はこちら(https://vaadin.com/features


ブラウザプラグイン不要


VaadinはGWT、JavaScriptベースなのでエンドユーザにプラグインのインストールを要求しません。


フレームワーク比較


VaadinとほかのJava Web フレームワークのサイドバイサイドな比較。
「フレームワーク比較(https://vaadin.com/comparison)」へ進んでください。


------
ビデオはまだ見ていないが、わかったことはGWTベースのフレームワークでUIのデザインツールなんかがあって短期開発アプリ向けだということ。

Apache2.0準拠のオープンソースであることはわかった。

数行のJavaコードでWebアプリつくれまっせ..っていうのは眉唾だなあ..やっぱり画面の作り方がどれだけ簡単かみてみないとなあ..


というかGWT関連の記事ってことごとくPVが一回り桁数少ないんだよなあ..
日本のGWTユーザはレッドコード扱いになっているのかもしれないなあ..

2014年7月10日木曜日

【解決しました】Proxy環境だとIBM BlueMix Tools EclipseプラグインからBlueMixサイトへ繋がらない




IBM BlueMixのハンズオンへ行ってきた人の資料を借りて
とりあえずデプロイするところまでためそうとしたのだけど..

プラグインをマーケットプレイスからインストールした後
サーバにあらかじめBlueMix上に作ったサーバを登録しようと
サーバタブ選択→右クリック「新規」>「サーバ」>「IBM: IBMBlueMix」
を実行、サーバを作ったアカウントのメールアドレスとパスワードを入れて
Validate Account」ボタンを押したら

Unable to communicate with server - I/O error on GET request for "https://api.ng.bluemix.net/info": api.ng.bluemix.net; nested exception is java.net.UnknownHostException: api.ng.bluemix.net





というエラーが出た。

ブラウザから「https://api.ng.bluemix.net/info」をたたくと

{"name":"BlueMix","build":"169001","support":"http://ibm.com","version":2,"description":"IBM BlueMix","authorization_endpoint":"https://login.ng.bluemix.net/UAALoginServerWAR","token_endpoint":"http://uaa.ng.bluemix.net","allow_debug":true}

上記のJSONデータが帰ってくる..

..ので見れないわけないんだけど..


で例によってプロクシかな..とおもい
プロクシではない環境で実行したら
すんなり次へ行った..


Cloud Foundry(MicroCloudFoundry)やOpenShift(LiveCD)はローカルの仮想環境イメージも提供しているので
BlueMixにもあるかと探したけど..ない..

検索力がないから見つからないのかもしれないけど..


IBMのサービスだから企業向けかと思ったけど..

企業なんかProxy前提の環境ばかりなのに
こんなんじゃ使い物にならないよ...

どのポート使ってるのか調べようかと思ったけど
たぶんPivotalみたいにMCFにかわるイメージをくばるんじゃないかなとおもい
諦めました..


だれか、プロクシ経由でもBlueMix上のサーバへデプロイできる環境作れたら
教えてください..



《2014/10/07追記》
実は、
IBMの担当者に聞いて"proxy経由で接続できる" との回答をもらった人がいて、
あきらめず再度試してみました。

どうも、
ウィンドウ>設定>一般>ネットワーク接続 で、
ネイティブ」設定でやっていると失敗するようで、
ここを「マニュアル」にしてプロクシサーバやポートなどをEclipse上に直接設定したら
うまくつながりました。

なんかβ版もでているようなので
最新のプラグインでは治っているかもしれませんが..


マーケットプレイスつながるんだから、
「ネイティブ」設定で全然大丈夫だったのに..


ハマった人、ご注意ください。

2013年12月11日水曜日

CloudStack4.2.0用の簡単なUIプラグインを作ってみる

※本投稿は、CloudStack Advent Calendar 12月11日のエントリです。


CloudStack4.2.0から管理サーバのWeb UIに対してプラグインが作れる
ようになった。
リリースノートにはUIプラグインの作り方については
詳しくはDeveloper Guideを読んでね」と書いてあった。

しかしDeveloper Guideが4.2.0リリースされて1ヶ月以上経つのに
ちっともでてこない..

なので、自分でちょっと管理サーバのWebコンテンツ内を
覗いてみることにした。

管理サーバのWebコンテンツディレクトリ内には

/usr/share/cloudstack-management/webapps

が管理サーバWeb UIのコンテンツが入っている。

更に下の

/usr/share/cloudstack-management/webapps/client/plugins

というディレクトリをみてみると、
plugins.jstestPluginディレクトリがおいてあった。


plugins.js上のcloudstack.plugins
プラグイン名を入れれば、
その名前のディレクトリ上のJavaScriptを読んでくれそうだな
と直感的にわかれよ、ということらしい。

むかしCloudStackのAPIを呼び出すURL文字列を作成する
AppEngineアプリ

CloudStack API Creator
https://cloudstacktools.appspot.com/

CloudStack API Creatorサイト作成に関する投稿
http://fight-tsk.blogspot.jp/2013/03/cloudstack-apiurl.html

を作ったのでこれをなんちゃってプラグインにしてみることにした。




まずプラグインIDを決める(apiUrlCreatorにした)。

そして、

/usr/share/cloudstack-management/webapps/client/plugins/plugins.js



    (function($, cloudStack) {
      cloudStack.plugins = [
         'testPlugin',
         'apiUrlCreator'
      ];
    }(jQuery, cloudStack));


と書き換え、

testPluginディレクトリを丸々

/usr/share/cloudstack-management/webapps/client/plugins/

ディレクトリ下にプラグインIDとおなじディレクトをつくってコピーして

/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/apiUrlCreator.js
 
(testPlugin.jsをリネーム)
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/apiUrlCreator.css (testPlugin.cssをリネーム)
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/config.js
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/icon.png


を作成し(念のためroot.rootで同じパーミッションにしておき)、

cofig.js は以下のソースに書き換え、

(function (cloudStack) {
  cloudStack.plugins.apiUrlCreator.config = {
    title: 'API URL String creator Plugin',
    desc: 'To create URL string with CloudStack API',
    externalLink: 'http://fight-tsk.blogspot.jp/',
    authorName: 'Hara Hara Development',
    authorEmail: 'SammoHungGambou@gmail.com'
  };
}(cloudStack));

apiUrlCreator.jsも以下のソースに書き換え、

(function (cloudStack) {
  cloudStack.plugins.apiUrlCreator = function(plugin) {
    plugin.ui.addSection({
      id: 'apiUrlCreator',
      title: 'API URL Creator',
      preFilter: function(args) {
        return true;//isAdmin();
      },      show: function() {
        return $('<div>').css('width', '100%').css('height', '700px').css('overflow', 'auto').html('<iframe height="98%" width="100%" src="https://cloudstacktools.appspot.com/" />');
      }
    });
  };
}(cloudStack));

最後に

service cloudstack-management restartをかけて
管理サーバWeb UIを使って一般ユーザ(ロールがuser)でログインすると..

左下に「プラグイン」と「API URL Creator」ってのができた。





以下の画面スナップは「プラグイン」を押下したところ。
現時点で有効なプラグイン情報が表示されていて、
今回作成した「API URL String creator plugin」も表示されている。




「API URL String Creator Plugin」を選択すると、
config.jsに書いた詳細情報がでてくる。




次に左側のメニューの一番下の「API URL Creator」の方をクリックすると
以下のスナップのようにGoogle App Engine上のWebサイトが表示される。



高さがあふれたのはご愛嬌..


apiUrlCreator.jspreFilterで常にtrueを返すようにすれば
一般ユーザも見えるプラグインになる。

<プラグインID>.js というファイルのshow部分
divタグにhtmlを埋め込むサンプルコード部分)を、
うまく書き換えてやれば複雑なプログラムも組むことができる。

DOM対象となる実際のHTMLファイルのdivタグにidが振られていないので
jQueryの呼び出しをそのまま使った。
#一つ上にid=shadowというdivタグがあって
#こっちを操作してやろうとしたらうまく行かなかった

UIプラグイン作成の鍵はCloudStack側が用意している
plugin.ui.addSessionというJavaScript関数。

この使い方のドキュメントがあればもっといろいろできるのに..


今回プラグイン関連ファイルをさわっているうちに
iframeが使えるがわかったので
前に作ったApp Engineサイトを流用したが、
同じコンテンツ内にServlet/JSPなりを書いてアプリを組む
なんてことも可能だろう。


CloudStackはAPIがREST通信なので同じサーバでなくてももちろん可能だが、
どうせならログイン中のユーザIDの権限でAPI操作できるような
JavaScriptを組みたい。



にしても..最近はJavaScriptを直接書く技術が必要なケースが増えてきた。
jQueryとかいちいちGoogleって書いていると生産性が悪いし..




企業内でCloudStackを使用する場合、
足りないのは利用などの申請系のワークフローと
課金機能なんだけど..

..誰か作ってくれんかなあ..

2013年11月12日火曜日

ガラポンTVを使ってみる

前から気になっていたガラポンTVを購入した。


ガラポンTVは、
ワンセグ局全局を内蔵もしくは外付けHDDへ記録するサーバで
価格は最近はだいたい約4万円前後で販売されている。

Regzaサーバは地デジを記録するので内蔵4TBでせいぜい1週間が
いいところだが、このガラポンTVはワンセグなので
画像は荒くはなるが記録する時間は内蔵ストレージだけで2週間、
3TB HDDを増設すれば90日間録画することができる。

Regzaサーバは同一セグメント内で他デバイスで再生可能であるのに対し、
ガラポンTVはユニバーサルプラグアンドプレイ対応のルータを使っていれば
外部のインターネット回線経由で再生が可能である。
但し特殊なポートを通信に使用しているため、
プロクシ経由での視聴はポートフォワーディングなどを行わない限りできない。

ルータのWAN側がグローバルIPアドレスであれば、
DHCPでの割り当てであっても屋外からも視聴できる。

どうもガラポンTVがIPアドレス変更を認識すると
ガラポンTVサイトへ変更されたことを伝達するしくみになっているらしい。

なので
屋外から視聴する場合は一旦ガラポンTVサイトへログインしてから
自宅のガラポンTVへ接続するので、
DHCPであっても受信可能なのだとおもう。


Regzaは画像品質重視であるのに対して
ガラポンTVは記録期間重視で
iPhoneやAndroidなどのスマートフォン、
iPadなどのデバイスでも視聴可能だ。
#無料の専用アプリが用意されている


私の自宅はインターネットマンションで
ユニバーサルプラグアンドプレイ対応のルータ経由で
使用しているが、
こんな環境であっても屋外からLTE回線で
iPhoneでTVを見ることができる。




自宅では無線LANで同一セグメントにつないでいたiPad経由で設定を行ったが
ルータの設定変更などややこしいルーティング関連の設定は自動だった。
#ユニバーサルプラグアンドプレイでないルータとか一部のルータは
#個別せってし無くてはならない

時間も30分くらいかな。
#一番長いのがワンセグのチャンネル検索だったがそのほかはほとんど時間がかからなかった。
必要なのは同軸ケーブルとLANケーブル(両方同梱されていない)。




国内の動画サイトは海外からの利用が不可な場合が多いが
このガラポンTVを使えば海外常駐者でもブロードバンド環境さえあれば
いつでも日本のTVを視聴することができる、というのが宣伝文句だ。

でもインドに半年いたけど
国内にあるサーバまでは距離が遠すぎて
回線速度が確保できなかった。
ニコニコ動画は当時国内サーバしかなかったので
ぶつぶつきれてしまいほぼ使い物にならず
もっぱらyoutubeへアップされた番組をちょこちょこみていた。

回線品質の良い国なら使い物になるかな..
くらいで思っていたほうが良いと思う。



本音を言えばストレージをクラウド上においてほしいところなのだけど、
たぶんTV業界の既得権益ホルダーな人たちがやいのやいのいうから
できないのだとおもう。
もしそうなっちゃったら
「TVの電波、いらないんじゃないの?」ってなっちゃうからね。

..生きてる間は難しそうだなあ..

2013年10月23日水曜日

CloudStack4.2.0をインストールしたら、システムVMがStartingのままになる




CloudStack4.2.0のdebパッケージが配置されていたので、
早速Ubuntu Server12.04LTSにインストールしてみた。

4.0/4.1/4.1.1/4.1.1-1と全く同じ手順でインストールを行い、
管理コンソールからいざ「ゾーンの有効化」をはじめると..

Secondary Storage VM、Console Proxy VM両方共「Starting」のままで
いくら待っても起動しない。
/var/log/cloudstack/management以下のログを見ると
Exceptionが発生していた。

システムVMが上がらない系の問題は
CloudStackインストールを試す人はぼぼかならず引っかかるが
その際の動きは微妙に違う。

多いのは起動→失敗→インスタンス作り直し→起動→失敗..を繰り返し
VMの名前の数字がどんどん上がっていくパターン。
#こっちはNFSのマウントオプションにミスが有ることが多い

今回はこれとは違うので、mountオプションの問題ではなさそうだ。


いろいろためしたがうまくいかない..

..で、ふと管理コンソールに「領域」という概念が増えていることに気づく。
もしかしたらVMのテンプレート自体がかわっとのかもしれない..

Install Guideを読んでみると..



4.5.9 Prepare the System VM Templateの記述で
cloud-install-sys-mount-tmpltコマンドの
KVMのテンプレートURLが

http://download.cloudstack.com/templates/acton/acton-systemvm-02062012.qcow2.bz


でなく

http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2

になっとる..



..気づくのに、1ヶ月かかった..

2013年10月8日火曜日

CloudStack4.2.0がやっとUbuntu Server12.04LTSでapt-getできるようになった

10月はじめに4.2.0がリリースされていたのだが、
何度かトライしたが、
Ubuntuのapt-getコマンドで取得できるような環境はまだできあがっていなかった。

しかたないのでdebファイルを直接入手してdpkg -iでインストールしていたが、
さきほどようやくapt-get/aptitudeできるようになった。

でも、ダウンロード速度が..遅すぎ..
cloudstack-managementなんて137MBしかないのに
1時間どころじゃない..
みんなやっているから?!

ソースから構築するのがスピード的には一番よさそうだ..



CloudStack4.2.0自体はまだしっかり試していないが、
管理コンソールに「アフィニティグループ」と「領域」の2つのメニューが増えていた。

領域はリージョンのことで、
別のDCにあるCloudStackを操作する時にサーバ指定を変えるなどかなと想像できるが..

アフィニティグループねえ..小集団で全員管理者とかかな?

もうちょっと調べてみるか..


p.s.

ちなみにインストールは4.1とほぼかわらないが
プライマリ指定のときゾーン全体にしてNFSサーバを登録するとエラーになるので
クラスタ指定でインストールすれば素直にセットアップがとおる。

ただし、ひっかかるのがSystem VMのテンプレートをダウンロードしてくる所。
URLが変わっているのだ。

それに気づかずに、4.1時代のテンプレートをセカンダリストレージにおいてしまうと、
例の「ゾーン有効化直後System VMが上がらない(ずーっと2つともStarting)」状態
に陥る。

# /usr/share/cloud-common/scripts/storage/secondary/cloud- 
install-sys-tmplt -m /mnt/secondary -u  
http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2  
-h kvm -F
 
ご注意を。 

2013年9月10日火曜日

CloudStackにおけるrealhostipの役割についてのwiki文書を翻訳してみる


コンソールProxy VMが使用しているrealhostip.com、
こっちでDNS設定していないのに勝手にDNS正引きして
コンソールを表示(したり、表示できなかったり)することを
疑問に思っていた。

CloudStack wiki をちょこちょこみていると
ふと

Role of realhostip in CloudStack

なるページを見つけた。

ので、ちょっと翻訳してみた。
正直ちょっとくせがあるので、正確に翻訳できたかは不明。
なので参照の際はくれくれもat your own riskでお願いします。

--------

CloudStackにおけるrealhostipの役割


どのようにrealhostip DNS名はCloudStack内で正確に処理されているのか、という質問を定期的にうけます。realhostip.comドメインは、異なるカスタマサイト内のすべてのCloudStackインストレーション間でHTTPS通信を動作させるために存在しますが、管理者無しでどうやってデプロイ環境の変更のためにSSL認証をロードしているのかを心配しているのです。

SSL認証はCloudStackシステムVMでHTTP接続を行う際に使用されています。例えば、コンソール proxy VM やセカンダリストレージVMなど、両方内部のHTTPサーバで使っています。
realhostip.com SSL認証は、すべての*.realhostip.com DNS名が認証を使用するとみなすワイルドカードアドレスでサインされています。各CloudStackカスタマは各々の環境を持つため、各カスタマの環境はそれぞれにシステムVMを保有し、各システムVMはそれぞれにIPアドレスを保有することになります。

異なるカスタマ間のすべてのインスタンスに適用するためある1つの認証を使用する場合、CloudStackによってホストされるダイナミックDNSサービスの提供する解決方法を漏らしてしまいますが、DDNSサービスは基本的に「xxx-xxx-xxx-xxx.realhostip.com to IP address xxx.xxx.xxx.xxx」というDNS名からIPアドレスまでのフォームに変換します。

CloudStackは各環境のIPアドレスをコントロールしているので、SSL認証が必要な時はいつでも、カスタマが環境を実行中であることは重要ではなく、そのようなDDNSサービスが有効なので、いつでも絶えず変更されるIPアドレス上でサフィックスがrealhostip.comであるドメインの割り当てが可能となります、これがすべてのCloudStack実行環境間である1つのSSL認証が一般的に適用可能とする我々のトリックです。

これらのケースの殆どでは、主な目的が(サイト認証の正確性ではなく)セキュアなコミュニケーションチャネルを確立することであるため、DNS名の醜さがエンドユーザに対して見せることはなありません、しかしながら、カスタマが面倒を見るケースもあり、それゆえ、コンソールproxy VMはユーザに対してユーザ自身のSSL証明書を使用するためのカスタマイズ可能な方法を提供します。

ケルビン

--------

そうかセキュアな通信をするためにSSL証明書が必要で、
証明書を作成するには何がしかのFQDNが必要になり、
それで*.realhost.comというワイルドカード証明書を作ったわけか。

で内部でDDNS機能を持たせてそこで名前解決させていた、と。

どうも文章がただしければ、こっちでSSL証明書やドメイン名はかえられるようだけど..

たしかにちょっとトリッキーな使い方してるなあ..

ご参考まで。

CloudStackにおけるドメイン、アカウント、ユーザ、そしてプロジェクトをどう使うか

CloudStackを本格的に使用する場合、ドメイン、アカウント、ユーザを作成しなくてはならないが、それらについてまず理解しておく必要がある。

そこで、以下のサイトを翻訳してみた。

Accounts, Domains, and Admin explained


以下、翻訳した文章である。
(参照の際はat your own riskでお願いします)

ここから--------

アカウント、ドメイン、管理者の説明


ドメインは複数のアカウントを保有する事ができます。各アカウントは複数のユーザを保有することができる。リソースの所有権はアカウントにひも付けされます。ユーザとは、丁度銀行口座において異なる利用者が銀行口座に対して参照権限をもつような、アカウントリソースへアクセススするための単なる同義語です。それぞれのユーザパスワードを持ちますが、同一の預金口座資金を使用します。CloudStack UIでアカウントやユーザを作成することで、より深く理解できるでしょう。

詳細

  • 1つのユーザは1つのアカウントにのみ所属することができます。同じユーザが複数のアカウントに所属することはできません。
  • どんなドメインレベルでアカウントを作成する場合でも、アカウントは、管理者(admin)と利用者(user)の2つのタイプがあります。もしアカウントが管理者(admin)の場合はそのドメインのドメイン管理者となります、そしてもしアカウントが利用者(user)である場合はそのドメインの一般ユーザとなります。
  • ROOTレベルで作成された管理者(admin)はルート管理者(ROOT admin)と呼称されます。ROOTがトップドメインなので、ルート管理者はすべてのリソースに対する操作特権を保有することとなります。
  • ユーザ名は所属するアカウントのドメイン内で一意となります。異なるドメイン(サブドメイン含む)であれば同じユーザ名が存在してもかまいません。
  • ドメイン名はフルパスが一意であれば同じドメイン名をつけることができます(例:ROOT/d1の場合、ROOT/foo/d1やROOT/bar/d2)。
  • リソースは、アカウント内の個々のユーザではなく、1つのアカウントの所属となります。課金やリソース制限などはゆーざごとではなくアカウントごとに管理されます。
  • CloudStackは、管理者(admin)アカウント、ドメイン管理者(domain-admin)アカウント、ユーザアカウントの3つの異なるタイプのアカウントの作成を許しています。すべてのロール(管理者(admin)、ドメイン管理者(domain admin)、ユーザ(user))はアカウントレベルに割り当てられます。CloudStack UI上で作成してそれぞれの違いを理解して下さい。
  • あるアカウントのすべてのユーザは同じ特権を保有します。1つのアカウントの役割ベースのユーザは存在しません。
  • 同一ドメインに複数の管理者を保有することができます。すべてのドメインはROOTドメイン以下に作成されます。

ここまで--------


アカウントは、いわゆるパーティパターンの"パーティ"に相当し、個人1名をあらわすことも部署などのグループを表すこともできる設計になっている。
ドメインもグループを表す論理単位なのだが、ドメイン間でのリソースが共用できないようなので、それこそクラウドビジネスでIaaSとしてCloudStackリソースを提供する際の契約単位とかに利用するため設計されたのだろう。
社内IaaSで他社が出てこない場合は、1つのドメインでも運用はできそうだが、ルートドメインにインスタンス数上限などのリソース制約が切れない以上、ルート以外に1つドメインは切っておいたほうが良い。

アカウント、ドメインも複数の人間が参加する組織や団体をあらわす論理単位だけど、CloudStackには"プロジェクト"という論理単位も存在する。

このプロジェクトについても理解しておく必要があるため、CloudStack wikiをさがしてみた。
するとQ&Aに以下のドキュメントを発見した。

Accounts, Domains, and Projects oh my!

以下、翻訳した文章である。
(こちらも、参照の際はat your own riskでお願いします)


ここから--------

アカウント、ドメイン、そしてプロジェクト、なんとまあ!



ドメイン


ドメインは(会社や団体など)組織の単位とほぼ同じです。ドメインは、(一般的に)リソースを所有していませんが、しかしドメインはドメイン範囲内のすべてのアカウントに対しリソース制限を強制することができます。ドメインはプロジェクトやアカウントを収容することができます、しかしドメインは本当にドメイン自身だけでインスタンス、ボリューム、他のリソースなどを所有しません。ドメインは、インスタンス、ボリューム、ネットワーク、スナップショット、テンプレートなどのようなリソースを所有できるその他のもののための器(コンテナ)です。ドメインは親ドメインに対して一意でなくてはなりませんが、その他のドメインの子であるなら(同じドメイン名を)繰り返すことができます(ROOT/dom1/sub1とROOT/dom2/sub1は"sub1"が一意ではありませんがそれぞれの親が一意であるため使用することができます)。

ルート(ROOT)ドメイン


ルートドメインは、すべてのドメインがルートドメインの子となるため、少々特殊です。ルートドメインの管理者アカウントは、すべての子ドメインに所属する(すべてのドメインの意、なぜならすべてのドメインはルート(ROOT)の子であるため)その他のリソースを(API経由で)操作する権限を保有しています。このためルートドメインの管理者アカウントは全体管理権限を保有することとなります。

本文書記述時点では、CloudStackはロールベースアクセス制御(RBAC)をサポートしていませんが、2つのレベルのパーミッション、管理者(admin)と利用者(user)が存在しています。アカウント名は1つのドメイン内で一意でなくてはなりませんが、すべてのドメインに対して一意でなくてもかまいません(joe@foo.tldとjoe@bar.tldは、"joe"が一意ではありませんが、foo.tldとbar.tldが一意ではないため、使用することができます)。

管理者アカウント


管理者アカウントはドメイン管理権限を保有しています。管理者アカウントは、ルート管理者により対象のドメインに対しドメイン制約(許可されるインスタンス数、ボリューム数など)を強制されていますが、多くの特権を保有しています。例えば、ドメイン管理者はドメイン内にアカウントを追加や、ユーザのAPIキーを生成する事ができます。自身のドメインのサブドメインを作成したり、ドメイン内のリソース利用状況をレポートする事もできます。

利用者アカウント


利用者アカウントは新規のリソース(インスタンス、ボリューム、スナップショットなど)を作成する権限を保有していますが、管理特権はとても少ないです。アカウントはAPIキーを生成できませんし、アカウントへユーザを追加することもできません、参照することだけは可能です。利用者アカウントが使用できるすべてのコマンドリストはAPIガイドを参照して下さい。

ユーザ名、パスワード、APIキー


ユーザ名、パスワード、APIキーはアカウントに属します。Web UI からユーザ名とパスワードを用いて、(そしてもしAPIキーが生成されているのであれば、APIキーを用いて)ログインします。ユーザ名は所属するドメイン内で一意でなくてはなりません(foo.tldドメイン範囲内の2つのユーザは同じユーザ名を持つことはできません-2つのjoo@foo.tldユーザを持つことはできません)が、異なるドメインであれば可能です(joe@foo.tldとjoe@bar.tld)。ユーザはリソースを所有することはできません、所属するアカウントが所有するリソースへの操作やアクセスといった単純な使い方のみです。ユーザは個別のパーミッションを保有することができません、ユーザが所属するアカウントのパーミッションを受け継ぎます。

アカウントとリソース


アカウントはリソースを所有します。アカウントはリソースを所有します、重要なので二度いいました。もしアカウントを削除したならば、所有していたすべてのリソース(インスタンス、ボリューム、スナップショットなど)は同様に削除されます。利用状況はアカウントレベルでも追跡されます。このため、課金やチャージバック目的のためにusageモジュールが有効である場合、アカウントレベルでのリソース使用状況のレポーティングが有効となります。

プロジェクト


プロジェクトはアカウントに似ていますが、アカウントとは違い特別な一面を持っています。プロジェクトはリソースの制御を複数のアカウントで共有することができます。リソース自身(インスタンス、ボリューム、スナップショットなど)はプロジェクトにより所有され、同一ドメイン内の複数のアカウントによる操作が許可されます。このため、ある組織内の複数の部署で取り組んでいる共同業務があるのであれば、プロジェクトを作成し他のアカウント(組織内の部署)を招待することで共同業務への参加を促すことができます。プロジェクトでは1つのアカウントはプロジェクト管理権限を委任しなければなりません。プロジェクト管理者は、対象ドメイン内の他のアカウントを招待したりアクセスを取り消す権限があります。プロジェクト管理者のみが対象のプロジェクトの操作権限を保有し、その他の(対象プロジェクトにアクセス可能な)アカウントに対する権限(例えば、許可されているインスタンス数やボリューム数、スナップショット数など)を保有していません。プロジェクト管理者が1つだけである間は、対象のプロジェクトが所有しているがそれに参加している個々のアカウントではないプロジェクトによって作成されたすべてのリソースであるため、影響を及ぼさないでアカウント間で移動することができます。


ここまで--------

翻訳しているとき業務としてのプロジェクトとCloudStackの論理単位であるプロジェクトが混ざっていて読みにくい..


CloudStackの論理単位である"プロジェクト"は、ドメイン内の複数のアカウントでリソースを共有でき、しかもまだ参加していないアカウントを"招待"することができる。
なので、プロジェクトは実業務上のプロジェクトと同じ考え方で切るほうがよいだろう。
ただ、usage server を使う場合は、アカウントとプロジェクトという単位以外では使用状況が追跡できないということは、システム監査などがうるさい企業で使用する場合は1アカウント=人間1人にして、1アカウント=1ユーザを守って管理していったほうがよいかもしれない。

とすると1企業内で使用する場合の例として

CloudStack 論理単位 実際の割り当て
ルート管理者 CloudStack管理を担当する人
ドメイン 会社名で1つ切る
ドメイン管理者 アカウントやリソース分配を管理する人
アカウント 社員1名
ユーザ 社員1名→LDAPユーザと対応
プロジェクト 社内の実プロジェクトと同じ単位、ドメイン管理者に作ってもらう
プロジェクト管理者 実プロジェクトの責任者アカウント、1名のみ。社員1名に紐付けないアカウントでも、責任者となる社員1名に割り当てても良い


とか..かな。

プロジェクト管理者のプロジェクトビューのダッシュボード画面にはアカウントタブがあり、このタブの中でプロジェクト管理者権限を他のアカウントへ渡したり、(既存の)アカウントをプロジェクトメンバとして追加したりできます。

ちなみに以下のタイプモデルは、CloudStack4.1.1の管理コンソールを眺めて個人的に書いたものです。



図の中のアカウントの役割の管理者は"admin"、一般利用者は"user"をあらわしています。また、プロジェクトでの役割のプロジェクト管理者は"Admin"、一般プロジェクトメンバは"Regular"をあらわしています。

役割を表す構造がすこしきもちわるいので、ひょっとしたら将来的には関係主体・関係主体ロールのパターンに変更になるかもしれませんね。となると画面仕様も変更になるかも..まあ、想像ですが..

この図も参照の際はat your own riskでお願いします。

Google Colab相当の環境をローカルPC上のDocker Composeで実現する

 Docker Composeの有料版に、お金を払いたくない ^H^Hが使えない ため古いゲーミングPC(GeForce3080)にDocker Composeを入れてその上のコンテナでGoogle Colab相当のノート操作ができないかためしてみた: コンテナイメージとして a...