作成者別アーカイブ: somof

Jenkins を MAcBookAirに再インストール

PHPの開発・テスト環境を作るため、
MAcBookAirにも、MBPRl2015と同じCI環境を用意する。

Jenkins のHPでは、こう書いてあるけど。

以前、ユーザー権限で動かすために
jenkins-runner.sh をチョコチョコとイジったのだった。

今回は、brewでサクっとインストールする。
jenkinsは以前は Cask だったけど、今は普通にインストールできる。
brewのメッセージは Cask の頃と違っていて

こんな感じ。
とりあえず、さっそく実行してみる。

あぁ、古いサービスが設定されたままだった。
どっちがどっちか分からないから、両方停止しよう。

ついでなので、古い.jenkins を消して、全部やり直すことにした。
これで Air でも、サッパリと最新版の Jenkins が使える。

ん? jenkins-runner.sh が見当らない。
まぁ良いか。
Airの方はデーモン化しないで、必要に応じて jenkins 直打ちで使うことにする。

ちなみに。
Caskの頃のインストール時のメッセージは、こんな感じだった。

Chrome の右上にIDが、しかも日本語で表示されるのをやめて頂く設定方法

Chrome の右上に日本語で名前が表示されてしまう。

しかも名字ではなく下の名前なので
日本人的に気持悪いと思う。

デザイン的にもどうかと思うし、
IDが一つしかなれば表示する必要でもないので、
さくっと消えて頂きたい。

ところが。
以前は、「新しいアバター メニューを有効にする」を「無効」にすれば良かったのに、
今使っている バージョン 44 のChromeには、設定画面 chrome://flags/ に、
その項目が無くなってしまった。

なんてこったい。

設定画面が無くなったので、
この日本語名の「新しいアバターメニュー」を消すには、
Chromeの起動オプションで –disable-new-avatar-menu というスイッチを指定する必要がある。

タスクバーにピン止めしている人なら、そのショートカットのプロパティで指定できる。
常駐型の拡張機能を使っている人は、全部止めてから再起動する。

Jenkins Visual Studio で自動ビルド その2

やっと今回の趣旨。JenkinsでVisualStudioの自動ビルド。

まず MSBuild Plugin をインストール。

その後「ビルド手順の追加」で
「Build a Visual Studio project or solution using MSBuild」を追加する。

設定画面で、使用する MSBuild.exe を指定する所で注意が必要。

「path:」に、例えば C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe を指定するのだけど、
バグがあるらしく、「フォルダーを指定せよ」的に怒られる。

ここで引き下がって、「C:/Windows/Microsoft.NET/Framework/v4.0.30319/」とかに変えると
実行時に「コマンドが無い」と言って当然動かない。
ひるまずに「C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe」と指定する。

今回はプロジェクトに含まれるデータが多くてcloneに時間がかかるので、
既存の Visual Studio のプロジェクト上で直にビルドすることにした。

ソース自体は、ローカルのgitで管理しているので、
ファイル監視を行うFSTriggerプラグインを使ってgitへのコミットをポーリングする。

Git plugin を使って SCMをポーリング を選ぶと、
コミットのコメントもJenkinsから見えて把握し易いのだけど、
今回は軽量・ご気楽な構成にしておく。

JenkinsでVisualStudioのワーニングをパースする

パースするプラグインは
Warnings Plugin より
Log Parser Plugin の方が
簡易で使い勝手が良い。

パースするための設定は

stackoverflow.com のQA
Good MSbuild log formatter? で、
VisualStudio向けのログの検索式がいくつか紹介されている。

とか

とか。

とりあえず、前者の設定で使っている。

Jenkins Visual Studio で自動ビルド その1

仕事の検証サーバのJenkinsを管理しているのだけど、
自分の開発PCのJenkinsは放置ぎみだった。

検証サーバはLinuxなので色々揃っていて扱い易いんだけど、
開発PCはWindowsなので、サーバ的に運用するのは案外手間がかかる。

一番気楽そうな MicroApache + Jenkins の組み合わせで、
完全に個人用にして使っていた。

だいぶんバージョンが古かったせいか、
プラグインをアップデートしようとしたら、
Jenkinsが動かなくなった… (汗)

以前使っていたプロジェクト類は、もう読み込めないみたいなので
何もかも全部削除して、新規に作り直すことにした。 (涙)

最新の Jenkins.war を壊れたJenkinsから拾ってきて、
とりあえず起動して、ブラウザから確認してみる。

認証つきにしろ、とか言われるけど、ローカルの個人使用だから無視。
会社のネットワークがIPV6に切り替わったので、プロキシーだけ修正した。

新しい Jenkinsって、どこを探しても再起動らしきものがない。
「シャットダウンの準備」を選んでも、いつまで絶っても終了しないし。

再起動画面に直にアクセスしても、
起られるだけど、再起動しない。

何か使い方が違うのか?
毎回強制終了でしのぐことにする。

もう一つハマった事は、git。

個人PCなので、Gitはローカルリポジトリで運用したい。
WindowsスタイルというかDOS形式で指定したり、
URL形式 file://〜 で書いても clone出来なかった。
一旦諦めたのだけど、試しに cygwin形式で書いたら、あっさり動いた。

/cygdrive/d/~ みたいに、cygwin形式でないとダメだった。
cygwinのgitを使ってしまったらしい。

長くなったので、本題の VS自動ビルドは次の記事で。

MSDNサブスクリプションが延長されてる

MSDNはライセンス料が高いので更新できず、
数年前に購入したライセンスのまま
Visual Studio 2010を使い続けてたのだけど。

今朝MSDNサブスクリプションのページを見たら
何か色々使って良い事になってた。

後で請求が来たらどうしようと思うと、
怖いので、やっぱり使えない。

emacs magitでソース管理

cygwin上のemacsから使い易い gitクライアントが無かったので、
Windowsでの開発では、ソースの編集はemacsでやっていても、
バージョン管理には TortoiseGit を使っていた。

TortoiseGit は GUIが上等なので、それはそれで便利なのだけど、
いちいちマウスを持つのが面倒なので、
編集に関わる作業は全部emacsの中で連続してやってしまいたい。

で、 magit を使うことにした。

今迄 emacs内でgitを触りたくなかったのは
cygwinのファイルアクセスが異常に遅いのが理由なのだけど、
最新のemacs-win64(25.0.50)とmagitの組み合わせなら何とかなる範囲。

で、インストール。

一旦、magitをGitHubからダウンロードしたものの、
中のドキュメントを見たら、 emacsのパッケージからインストールできる、
という事だったので、そっちに方針変更。

ドキュメント内では、 Melpa と Marmalade のパッケージが説明されていたけど、
結局、 Elpa 内の magit を使うことにした。

使用している git は 2.5.0、emacsは25.0.50 なので、
動作条件は満しているものの、 emacsがHEADのせいか、
こういう状況だった。

  • Melpa は、パッケージ自体に問題がちょいちょい起こるのでリストから外している
  • Marmalade の Magit は、バージョンが 1.2 だったけど、エラーで動作せず
  • Elpaの Magit は、バージョンが 0.8.1 で、かなり古いけど、問題なく動作する

Elpaのパッケージは更新されそうにないので、
そのうち GitlHub の Magit 2.1.0 に乗り換えるかも知れない。

で、Magitの使用方法は、とても簡単。

で、今のソースの更新状況が表示される。

これが emacs に出るのが本当に嬉しい。
うっかり編集や、気の迷いでチョット修正したのを忘れてしまう、
という、本当におバカなミスを防いでくれる。

TortoiseGit だと気付くタイイングが大分後になってしまうし、
そもそも作業が億劫なので、こまめに commit しなくなるから
gitの有難味が、ちょっとそがれてしまう。

emacs の magit-status 画面で普段使う機能は以下の通り。

  • s でファイルを一つ add
  • S 全ファイルを全てadd(git add -A)
    • 実際には C-u S とする
  • c コミット
  • u addの取消
  • l ログ一覧表示
  • L ログ一覧詳細表示

Macでの作業は、基本個人のローカル運用なので、コレで十分。

Windowsの開発案件で必要な pull/push/merge などは、
今のところ TortoiseGit を使っている。
外部と関わる重要作業は、GUIがしっかりしていた方がちょっと安心なので。

emacs org-modeで画像をインライン表示する

などして、
(org-toggle-inline-images) の所で C-c C-c とすると
インライン画像が表示される。

上にやり方だと、トグル動作の状態が

とか

とか、orgファイル上に勝手に追加される。
それがイヤな場合は、 M-X org-toggle-inline-images でOK。

としておけば、常のインライン表示されるけど、
普段は邪魔なのでトグル動作にしてる。

この書式のままで、
画像ファイルの転送も含めて WordPress の記事が書けると、
ブログを書くのが楽になるんだけどなぁ。

プラグインを書くのに、
またWP-MarkDownとケンカするのを解決するのが面倒そうだ。
WordPressでは MarkDown書式が一般的だしなぁ。

いっそMarkDownをやめて、
全て org-mode で書くプラグインを作るか…

emacs の起動時間が遅いと感じたら initchart.el。 これは面白い

initchart.el が素晴しい。
解り易さと、面白さで。

load-path の通った場所に initchart.el を置いて、
init.el の先頭に下記を追加して実行すると、
起動時間を計測してくれる。

initchart バッファに測定結果らしきものが出て来る。
ここでうっかり、initchart バッファを削除すると、
emacs が正常終了できなくなるので要注意!

emacsが起動したら、

を実行すると、 SVG filename: と聞かれるので、
~/initchart.svg など、適当なファイル名を入力すると、
そのファイルに計測結果が出力される。

~/initchart.svg をブラウザに読ませると、
起動中にかかった時間を各関数ごとのチャートにして、
綺麗に表示してくれる。

僕のemacsの計測結果は、こんな感じ。
表にしてしまうと initchart の面白さは無くなってしまうけど…
svgで表示してくれるので、時間がかかっているパッケージが
一目でで確認できるのが良い。

|————+———-+———————|
| パッケージ | 起動時間 | メモ |
|————+———-+———————|
| helm | 3.1秒 | ほぼ helm-files |
| howm | 1秒 | howm-varsが 0.4秒 |
| magit | 0.9秒 | ほぼ log-edit/messa |
| org | 0.6秒 | |
| w3m | 0.6秒 | |
|————+———-+———————|

主に履歴やメモ類のファイル読み込みに時間がかかっているみたいだ。
どれも必要な手順だから、しょうがないか。

howm/magit/org/w3m あたりは遅延呼び出しにしても良いけど、
それでも半分程度にしか短縮できないし、
どうせ朝に一回、数秒待つだけだから、このままにしよう。

ちなみに。
全く同じ設定ファイルでも Macのemacs は、 ほぼ瞬間で起動する。

MacBook はSSDだからね。
むしろ、OSXのウインドウのアニメーションを止めたいくらい。

2015年、お盆の円高は来るのか?来たのか?

来たと言えば来た。

ここ10年くらい、ドル安・円高傾向が強いようだけど、
実際のところ、そんなに高い確率ではないように思う。

今年の盆の円高も1円くらいのもの。
原因は、主に中国の形振り構わない金融施策と人民元の切り下げ。

日本からの買い支えが無いので、何かあったら円高に転び易いのだろう。

一時的な要因なら、盆明けに戻す可能性が高いだろうから、
収益チャンスと考えた方が面白い。

今年も、多分すぐに戻すと思うので、
ドルとトルコリラはポジションを追加しておいた。

さて、本当に戻すかな?

レバレッジネタ

面白いサイトを見付けた。

FXのレバレッジについて。


試しに計算してみましょう。スワップ派のサイトによると、USDJPYのHVはσ=6.95%であるので、今回は確実に安定して運用するために95%の確率で収束する2σを採用します。またμの値はUSDJPYのスワップポイントである、2.1%を採用します。そしてdを50%とすると、Lの値は
L = 50 / (6.95*2 – 2.1) = 4.24[倍]
となるので、レバレッジが4倍以内であれば、およそ95%の確率で安全圏に収束するということが分かります。

他のサイトや本でも、いろんな計算やシミュレーションがあるけど、
大体 3〜4倍に落ち着く。(みたいだ)

僕の場合は数式ではなくて、
2007年以降の為替データの最悪値に対して、
安全目に見積ってる。

その結果、今日現在の口座のレバレッジを計算すると 4.32倍だった。
予備の予算を加えたら、大体3倍位になる。

僕の今のポジション上の式に当て嵌めて計算すると、
2σで L = 6.7 、3σで L = 3.3。

今のポジションは 99.7%以上の確率で安全、ということだ。

だけど。
実際の取引では、 落ちきったところで仕掛けるのが一番いい。

攻めるためにも、普段のレバレッジはもっと低めの方が良い。
金融緩和が怪しくなってくる前には、しっかり撤収しとかなきゃ。