スキップしてメイン コンテンツに移動

OpenShift Origin

OpenShift Originを試してみる。Windows7 PCをホストOSとしてやってみる。

ゲストOSの準備

OSイメージをダウンロード。
https://www.openshift.com/products/origin

そのままVM Ware Playerで動くの動かす。起動するとVM Ware Toolsを入れるように言われるが、入れなくて良いと思う。起動するとVMのIPアドレスが表示されるので、あとで必要になる。

上記VMのIPアドレスを叩くとコンソールが表示される。
アプリケーション作成の画面でとりあえず適当な言語のアプリを作ることにする。とりあえずPython2.7のアプリにしておく。

ドメイン名とアプリ名は適当に決める。アプリ名はtestapp、ドメイン名はhogehogeとすると以下のようなアプリ用FQDNが決まる。

testapp-hogehoge.openshift.local

ホストOSはこのような名前を知らないのでHOSTSファイルに記入する。
https://www.openshift.com/wiki/build-your-own-paas-from-the-openshift-origin-livecd-using-liveinst#Use_the_PaaS_from_the_Local_Network

これでホストOSのブラウザからtestapp-hogehoge.openshift.localをアクセスするとデフォルトコードで動作しているアプリが見える。virtual host機能で振り分けているのかなぁ。

ホストOSでの開発環境

puttyを入れる。自分の環境はインストール済みなのでパス。

ホストOSで開発するためにrhcツールをインストールする必要がある。
まずはruby1.9とgitをインストールする。

LIBRA_SERVER環境変数に上記VMのアドレスをセットする。

set LIBRA_SERVER=上記IPアドレス

これでrhc setupを実行する。

gitが使えるようにするための説明は以下のページを参考にした。

自分の場合gitからssh通信するために以下の環境変数をセットした。

set GIT_SSH=c:\Program Files (x86)\PuTTY\plink.exe

途中半角スペースがあるが、ダブルクォーテーションで囲ってはいけない。

rhc app show -a testapp

を実行しアプリの詳細情報が出ればOK。
この中にgitアクセス用のURLの記述があるので、これでgit cloneする。

git clone ssh://URL

あとは以下の記述通りソースコードを修正してコミット、プッシュする。

改めてブラウザからtestapp-hogehoge.openshift.localをアクセスすると修正したページが出てくる。
よかったよかった。

ラベル:

コメント

コメントを投稿

このブログの人気の投稿

ST-M310 シフトレバーのカバー開け

通勤用のCylva F24のリアディレイラーの変速の調子が悪いので調整した。完ぺきではないし、購入してからもうすぐ2年、走行距離は5000Kmは超えているはずなのでシフトケーブルも見てみたいと思い、シフターの分解をやってみる。 マニュアルはこちら。 https://si.shimano.com/pdfs/dm/DM-SL0001-09-JPN.pdf 20ページがALTUS、つまりST-M310のはず。 ねじを外せば太鼓部分を隠しているカバーが取れるように見えるけど、自分の場合二つ問題が。 一つ目はカバーがブレーキレバー部分にぶつかって取れない。Cylva F24についているシフターはブレーキレバーと一体型になっている。型番はよくわからない。マニュアルはシフターのみしか書いていないので、蓋が簡単に取れるように見えるけど、ブレーキ部分にぶつかって上には外れない。結局ブレーキ部分に当たる側をマイナスドライバーで側面の高さ分持ち上げた。 二つ目は爪の存在が説明されていない。マニュアルにはひっかけ部分の説明があるけど、そもそもインジケーターの裏が爪になっていてカバーが引っ掛かっている。この爪は真ん中に3mmぐらいの間があるので、ここにマイナスドライバを突っ込んでてこの原理で無理やり開ける必要がある。 カバーを外すとたぶんインジケーターが吹っ飛ぶけど、これは見れば直す方法はわかる。 で、中身を確認したけどきれいなもんでさびなどないし、ワイヤーの切れ・ほつれもなかった。
コメントを投稿
続きを読む

Ride with GPSで作成したルートのgpxファイルとOruxMapsの関係

Ride with GPSのAndroidアプリによるナビゲーションはOruxMapsと比較して告知がしつこくない。設定があまり多くないので仕方がないが、キューシートのポイントに対して一回しかアナウンスがない（もう一回ぐらいあるかな？）。またルート外に出た場合は地味な警告音と文字の通知しかない。 OruxMapsだと、ポイントの何メートル前で警告を出すか、最大何回出すか指定できる。街中だとうるさいぐらいしつこくアナウンスが出る。同様にルート外に出た場合も、しつこくしつこくアナウンスが出る。 たぶんブルベだとこれぐらいしつこい方がミスコースをなくすためにはいいと思う。 そうすると、Ride with GPSで作成したルートを使ってOruxMapsでナビゲーションするのがよい。 色々試した感じではGPXトラックのExportで、経路マーカーとしてPOIを含めると経路マーカーとしてキューを含めるをチェックすると、POIとキューがgpxのWayPointとしてExportされる。 キュー キューはWayPointとしてExportされる。RWGPSの「種類」として選んだものがnameに入り、注記に入れたものがdescとcmtに入る。   <wpt lon="139.5624979" lat="35.5408905">     <name>Straight</name>     <cmt>PC1</cmt>     <desc>PC1</desc>     <sym>Dot</sym>     <type>Dot</type>   </wpt>   POI POIの名前として入力したものはnameに入る。 <wpt lon="139.60360027326055" lat="35.565638161972615"> <name>フオトチェック</name> <sym>Dot</sym> <type>Dot</type> ...
コメントを投稿
続きを読む

DJI Osmo Action 4 ジャイロデータ

手振れ補正を後処理にすることで消費電力を下げられないかテスト。 手振れ補正をオフにすると以下の画面が出たので、2.7Kの16:9で動画撮影してみた。 補正ソフトを調べたところGYROflowが見つかった。 https://gyroflow.xyz/ 早速GYROflowに読み込ませるとモーションデータがない、レンズプロファイルが読み込まれないとのエラーになる。 いろいろ試したところ4:3画角にしないとジャイロデータは保存されない様子。H264でもHEVCでも大丈夫。 4K 4:3画角で撮影したところ、GYROflowでモーションデータを認識し、レンズプロファイルも検知された。再生した感じはいい感じにブレが補正されている。バッテリーの消費は1%あたりの録画時間は20%ほど増えた。比較対象は4K 16:9なので厳密には同じではないが、違いは明確。とはいえ、FHDで撮影するよりやっぱりバッテリーを消耗する。 kdenliveにstabilizeという機能があるので、FHD画像のブレ補正をやってみた。Intel Core i5-9400@2.9GHz（ディスクリートGPUなし）だと処理時間がかなりかかる。ちゃんと測定しなかったが、録画時間以上かかっていると思う。画角は狭くなるが効果はある。何もしないより全然いい。ただ、RockSteadyモードとの比較だと1%あたりの録画時間はほとんど変わらない。 今のところハイパーラプスモードが一番消費電力が少ない感じ。次は50フレームのx2モードで撮影してみよう。普通速度が欲しければ25フレーム表示すればいいはず。
コメントを投稿
続きを読む