カテゴリー別アーカイブ: program

org2blogで、wordpressで書いてあった記事を更新する方法

検索すると、org2blogではwordpressで書いてあった記事を更新できない、 と書いてあるブログがちらほらある。

元の記事をHTMLで書いていたら難しいけれど、 テキストで書いてあれば、それ程難しくはない

Worpressから、既存の記事をダウンロードする

ここで、Wordpressのエクスポート機能を使うと HTML状態でダウンロードしてしまうので、org2blogとしては面倒なことになる。

HTMLタグを取り除けば良いのだけど、数が多いと手間もバカにならない。

なので。 CSV Exporter の様な、テキストでエクスポートしてくれるプラグインを使うとOK。

公開日時やカテゴリも一緒にダウンロードできるので便利。

org2blogで書き直し

bufferで投稿するならOPTIONで、subtreeで投稿するならプロパティで、 以下の様な属性を指定してあげる。

投稿IDを、元記事と同じにすれば、上書きする事が出来る。

:POSTID: 投稿ID
:POST_DATE: 公開日
:CATEGORY: カテゴリ
:TAGS: タグ

magit と git-gutter が便利!

git-magitを使ったソースコードの履歴管理は凄く便利。 git-gutter-fringe を追加すると、commitした後の更新が常に見えるようになる。 これはズゴク便利。

MELPAから自動でインストール出来て、Macでは言うこと無しに快適。 Cygwinでは、この間までは良くプチフリーズしていたけれど、 設定見直しでファイルアクセスが早くなったので実用範囲になった。

設定したのは、この程度。

;; Control Git from Emacs.
(require 'magit)

;; magit
(global-set-key         (kbd ""C-z m s"")       'magit-status)

;; git-gutter-fringe
(global-git-gutter-mode)
(global-unset-key       (kbd ""C-z g""))
(global-set-key         (kbd ""C-z g t"")       'git-gutter:toggle) ; Toggle git-gutter
(global-set-key         (kbd ""C-z g p"")       'git-gutter:previous-hunk)
(global-set-key         (kbd ""C-z g n"")       'git-gutter:next-hunk)
(global-set-key         (kbd ""C-z g r"")       'git-gutter:revert-hunk)
(global-set-key         (kbd ""C-z g u"")       'git-gutter:popup-hunk) ; popup diff
(global-set-key         (kbd ""C-z g s"")       'git-gutter:set-start-revision) ; Set start revision where got diff
(global-set-key         (kbd ""C-z g g"")       'git-gutter) ; Show changes from last commit or Update change information.
(global-set-key         (kbd ""C-z g c"")       'git-gutter:clear) ; Clear changes

git最高だなぁ。

Mac El Capitan で Jenkins がデーモンとして起動しなくなっていた件の修正

El Capitan にアップデートしてからJenkins が起動しなくなっていた問題の修正。

まず、ログすら残ってないので。

$ sudo chown jenkins /var/log/jenkins/

で、 launchctnl start して結果のログを見ると、こんな感じ。

前半はオプション指定が無いと言っているだけで、 jenkins.war へのパスが通っていないのがエラーの原因らしい。



The domain/default pair of (/Library/Preferences/org.jenkins-ci, war) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, JENKINS_HOME) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, prefix) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, httpPort) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, httpListenAddress) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, httpsPort) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, httpsListenAddress) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, ajp13Port) does not exist

The domain/default pair of (/Library/Preferences/org.jenkins-ci, ajp13ListenAddress) does not exist

JENKINS_HOME=/Users/Shared/Jenkins/Home

Jenkins command line for execution:

/usr/bin/java -Dfile.encoding=UTF-8 -XX:PermSize=256m -XX:MaxPermSize=512m -Xms256m -Xmx512m -Djava.io.tmpdir=/Users/Shared/Jenkins/tmp -jar /Applications/Jenkins/jenkins.war

Error: Unable to access jarfile /Applications/Jenkins/jenkins.war

plist で指定している jenkins は

/usr/local/opt/jenkins/libexec/jenkins.war

なのに、デーモンは

/Applications/Jenkins/jenkins.war

を探しにいって、見付からないので起動に失敗しているらしい。

agentを見てみると、jenkinsが二種類登録されていて、 古い設定が使われていたままの様だった。

~ $ launchctl list|grep jenkins
– -9 homebrew.mxcl.jenkins
– 78 org.jenkins-ci
~ $ launchctl remove homebrew.mxcl.jenkins
~ $ launchctl remove org.jenkins-ci
~ $ launchctl list|grep jenkins
~ $ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist
~ $ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist
~ $ launchctl start homebrew.mxcl.jenkins

またログファイルの所有者がrootになってしまうので 以下の様に、改めて登録と実行。

~ $ sudo chown jenkins /var/log/jenkins/
~ $ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkinsp.list
~ $ launchctl start homebrew.mxcl.jenkins

この状態で、コマンドで起動すればJenkinsを使えるのだけれど、 デーモンとして起動しない状況は変わらず。

どうやら、 plistの値が使われず、 mac の defaultコマンドの値が使われているらしい。

~ $ defaults read ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist

で、defaultを上書きしてあげる。

これで、デーモンとして jenkins が復活してくれた。

gitのローカルリポジトリをローカルで共有したい

gitでワークスペースを複数作って違う作業をしたい場合に、
リモートのサーバを用意して、リポジトリを共有していた。

バックアップも兼ねているので、それはそれで良いのだけど
もっとご気楽にローカルのリポジトリを共有する方法があった。

[[http://d.hatena.ne.jp/bi_na/20120206/1328502980][gitのローカル用の共有リポジトリ(?)を作る方法Add Star]]

workspace/orginal/ に既にgitのローカルリポジトリがあるところから。

#+BEGIN_SRC sh
$ cd repo
$ git clone –bare workspace/orginal/ # ← 元のリポジトリから新しい共有用リポジトリを作る

$ cd workspace/new/
$ git clone repo/orginal.git # ← 新しいワークスペースを作る

$ cd workspace/orginal
$ git remote add origin repo/orginal.git # ← 元のリポジトリに origin を設定
#+END_SRC

ポイントは2つ。

まず、
元のリポジトリから新しい共有用リポジトリをcloneする際に –bare オプションをつけること。
これで、リポジトリとして必要なファイルだけがcloneされる。

もう一つが、
元のリポジトリに、今作った共有用リポジトリをoriginとして設定すること。
これで、元のリポジトリのフォルダも、引き続きワークスペースとして使用できる。

Adobe DC/Readerの読み上げ機能がしつこいので

Adobe のpdfソフトが目紛しく更新されて、
段々と重くなっているなぁ、と思うこのごろ。

いつ頃からか、仕事のpdf書類を開くと
文章の読み上げ画面が表示される様になり、
特許資料などの大量に書類を見る作業の邪魔になっていた。

もう業務妨害と言って良い程。

設定画面を見ても、読み上げ機能を停める方法が分からず、
ネットで調べてみた。

職場で、pdfの読み上げ機能を使う事は無いだろうし、
以下の方法が確実で良さそう。

フォルダの場所は、バージョン毎に違いそうだけど
C:\Program Files (x86)\Adobe\Acrobat 11.0\Acrobat\plug_ins
にある、以下の2つのファイルを削除する。

– Accessibility.api
– ReadOutLoud.api

これで、読み上げ機能が無効化されスッキリ。

pdfファイルの読み込みが劇的に早くなるので
書類が沢山ある時の作業効率も、改善してラッキー。

というか、読み上げ機能のせいで、こんなに遅くなってたのか…
今迄の無駄に過した時間の長さを思うと、ちょっと残念な気分になる程。

Ubuntuのターミナルソフトの起動方法

必要にせまられてUbuntuをインストールした話。

余計なPCなどあるハズもなく、死蔵していたVMWareのライセンスを使って
開発用PCにインストールしたものの、ターミナルソフトが起動出来ない!(汗)

何、このGUIオンリーな画面は…

CUI環境が無いと始まらない仕事内容なので調べてみると、
ショートカットキー「Ctrl+Alt+T」でターミナルソフトが起動するらしい。

一度端末が開いたら、すかさず画面左のLauncher*に表示された端末アイコンを右クリックして、
「Launcherに登録」をクリックしておくと、次からはGUIから起動できる。

python min/maxで、リスト中の最大/小値の場所も知りたい

備忘録。 なにげに便利な pythonのmin/max。

max(nums, key=abs)

とするだけで、絶対値の最大値を探してくれたり。融通が効く。

リスト中の最大値だけでなく、最大値があった添字(場所)も知りたい場合は

item = max([(v,i) for i,v in enumerate(list)])
item[1]

とか。

ネットで検索すると、辞書に変換してから key を出す人の方が多いみたいだ。

max(dict, key=(lambda x: dict[x]))

とか、

max([(v,k) for k,v in dict.items()])[1]

とか。

でも、 enumerate の方が可読性が良くて好きだな。

cygwinのファイルアクセスが遅い件:もっと解決編

magit を更新したら、表示が綺麗になった代わりに、反応がとても遅くなってしまった。

ファイルの更新情報を色々と表示してくれるのは助かるのだけど ファイルアクセスが遅い cygwin 上では、かなりストレスに感じる。

もちろん macやlinuxでは問題なくて、快適そのもの。

そこでもう少し、Cygwinのファイルアクセスの速度を改善してみる。

;; vc無効化は出きないけど、無力化が出来る
(setq vc-handled-backends ())
(eval-after-load ""vc""
  '(remove-hook 'find-file-hooks 'vc-find-file-hook))

まだ動作がモッサリした感じだけど、大分快適にはなった。

為替予想再開への準備運動 その2

この3ヶ月間のバックテストの結果をレビューしてみる。 その2。

通貨別バックテスト結果のまとめ (30日、60日、90日)

それぞれの通貨のシグナルの回数と、勝敗結果。

通貨 回数     利益機会     勝敗    
  30日 60日 90日 30日 60日 90日 30日 60日 90日
USDJPY 4 1 1 1.78 2.18 4.23 LLLW W W
AUDJPY 1 4 6 3.60 7.50 10.20 W WWWW WWWWWW
CADJPY 2 9 1 1.75 3.00 8.25 WW WWWWWWWWW W
EURJPY 2 3 7 4.28 5.28 1.93 WW WWW LWWWWWW
GBPJPY 4 5 1 3.80 10.72 7.20 WWWW WWWWW W
NZDJPY 2 1 3 6.85 6.55 11.60 WW W WWW
TRYJPY 1 7 7 1.91 2.85 4.80 W WWWWWWW WWWWWWW
ZARJPY 0 1 1 0.00 0.23 0.23   W W
AUDUSD 1 6 2 1.66 3.96 5.10 W WWWWWW WW
EURUSD 2 9 12 5.84 5.85 7.50 WW WWWWWWWWW WWWWWWWWWWWW
NZDUSD 2 4 7 6.15 4.55 2.10 WW WWWW WWWWWLW
合計 21 50 48 37.62 52.67 63.14      

今週までの3ヶ月間を通して、それなりに値幅が取れて予測可能だった通貨は、 AUDJPY、EURJPY、NZDJPY、AUDUSD、EURUSD、NZDUSDあたり。

USDJPYは見事なレンジ相場で、テクニカル指標はダマシが多い。

細かくバックテストの結果を見て行くと

3種類のバックテストの結果を定性評価してみた。

通貨 sim1 sim2 sim3 メモ
USDJPY ×     少し前の水準に戻ったところ、慎重に
      10/23 BUY 121.430 T 123.250 L 119.900 D -1.530 +1.820 (36) エネルギーはかなり貯まっている
      × 10/23 BUY 121.430 T 127.600 L 119.600 D -1.830 +6.170 (31) エネルギーはかなり貯まっている
AUDJPY ×      
       
      10/23 BUY 87.610 T 89.000 L 86.500 D -1.110 +1.390 (14) いびつなシグナル
CADJPY     92.3 を越えれば 93.5 まで
      92.3 を越えれば 92.975 まで
      ×  
EURJPY     10/23 SELL 133.720 T 132.900 L 135.600 D -1.880 +0.820 (8) ターゲットに至らず大幅反落中
    ×   10/23 SELL 133.720 T 131.600 L 136.400 D -2.680 +2.120 (11) 綺麗な反落中 132.6 くらい有り得そう
      10/23 SELL 133.720 T 134.950 L 135.600 いき過ぎ感のある反落中
GBPJPY     10/23 BUY 185.920 T 185.500 L 182.500 ターゲットを越えて上昇中 187.45 も有り得る
      10/23 BUY 185.920 T 185.850 L 181.200 丁度ターゲット水準
      × 10/23 BUY 185.920 T 188.800 L 181.200 D -4.720 +2.880 (7) 今度こそ 189円のせするか?
NZDJPY     10/23 BUY 81.950 T 82.300 L 79.400 D -2.550 +0.350 (4) 持ち直して再度上昇中
      10/23 BUY 81.950 T 83.200 L 79.400 D -2.550 +1.250 (6) 微妙に有り得そうな形
      × 10/23 BUY 81.950 T 82.650 L 79.350 D -2.600 +0.700 (5) 82.65くらいは有りそう
TRYJPY     ターゲット到達後の反落中
      ターゲット到達後の反落中
      ターゲット到達後の反落中
ZARJPY      
      8.85 を下れば 8.0 まで大幅下落
      8.85 を下れば 8.0 まで大幅下落
AUDUSD     10/23 SELL 0.721 T 0.712 L 0.736 D -0.015 +0.009 (9) 綺麗な反落
      10/23 SELL 0.721 T 0.719 L 0.736 D -0.015 +0.003 (6)
      10/23 SELL 0.721 T 0.707 L 0.735 D -0.014 +0.015 (10)
EURUSD     10/23 SELL 1.101 T 1.091 L 1.127 D -0.025 +0.011 (7) ターゲット到達後の大幅反落、行き過ぎ感あり
      10/23 SELL 1.101 T 1.127 L 1.147 到達済み 大幅に行き過ぎ感あり
      10/23 SELL 1.101 T 1.127 L 1.147 到達済み 大幅に行き過ぎ感あり
NZDUSD     蓄積中 0.6690 より下げれば 0.651 、 0.678 より上げれば 0.700 まで
      蓄積中 0.6700 より下げれば 0.664 、 0.679 より上げれば 0.686 まで
      蓄積中 0.6703 より下げれば 0.683 、 0.679 より上げれば 0.682 まで

週末に大きな動きがあったばかりなので、シグナルの出方はまちまちで方向感が明確じゃない。

USDJPY が更に上昇するか、いつも通り反落するかで、変わってきそうなので、 来週は様子見かな。

考察

sim1〜sim3 は、最適化する期間が違うだけなのだけれど、 これだけバラつくのは、過学習してしまってるんだろうなぁ。

ターゲットへの値幅が小さ過ぎるのが多いし、 最適化の都合でシグナルが消滅してしまうのは扱いにくい。

最適化の方法から見直した方が良さそうだ。

cygwinのファイルアクセスが遅い件:解決編

もうmagit無しではemacsでコーディングできない体になってしまった。 さらに便利を求めて git-gutter-fringe+ をインストールしたところ、 Macではもう最高の使い心地。

だけども。 これをCygwinとntemacsで使うと、しょっちゅうプチフリーズしてしまう。 Cygwinのファイルアクセスが異常に遅いせいなのだけれど、 仕事上Cygwin環境は必須だし、git-gutterは手放したくないし。

いくら便利でも、作業中に30秒も固まられると、さすがに我慢できない。 いい加減、ちゃんとCygwinに対策をしなければ…

と言う訳で。

Cygwinの起動やファイルアクセスが遅くて怪しい場合に

CygwinのFAQサイト を検索してみた。

以下、Cygwinのページから引用。

4.2. Starting a new terminal window is slow. What’s going on?

There are many possible causes for this.

~snip~

For almost all its lifetime, Cygwin has used Unix-like /etc/passwd and /etc/group files to mirror the contents of the Windows SAM and AD databases. Although these files can still be used, since Cygwin 1.7.34, new installations now use the SAM/AD databases directly.

To switch to the new method, move these two files out of the way and restart the Cygwin terminal. That runs Cygwin in its new default mode.

~snip~

For the AD case, it can be slower than the old method, since it is trading a local file read for a network request. Version 1.7.35 will reduce the number of AD server requests the DLL makes relative to 1.7.34, with the consequence that you will now have to alter /etc/nsswitch.conf in order to change your Cygwin home directory, instead of being able to change it from the AD configuration.

If you are still experiencing very slow shell startups, there are a number of other things you can look into:

One common cause of slow Cygwin Terminal starts is a bad DNS setup. This particularly affects AD clients, but there may be other things in your Cygwin startup that depend on getting fast answers back from a network server.

~snip~

Another cause for AD client system is slow DC replies, commonly observed in configurations with remote DC access. The Cygwin DLL queries information about every group you’re in to populate the local cache on startup. You may speed up this process a little by caching your own information in local files. Run these commands in a Cygwin terminal with write access to /etc:

getent passwd $(id -u) > /etc/passwd getent group $(id -G) > /etc/group Also, set /etc/nsswitch.conf as follows:

passwd: files db group: files db

~snip~

Either in addition to the previous item or instead of it, you can run cygserver as a local caching service to speed up DC requests.

~snip~

A less preferable option is to create a static read-only cache of the authentication data. This is the old-fashioned method of making Cygwin integrate with AD, the only method available in releases before 1.7.34. To do this, run mkpasswd and mkgroup, then put the following into /etc/nsswitch.conf to make Cygwin treat these files as the only sources of user and group information:

passwd: files group: files

~snip~

If none of the above helps, the best troubleshooting method is to run your startup scripts in debug mode. Right-click your Cygwin Terminal

~snip~

4.3. Why is Cygwin suddenly so slow?

If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.

要するに、ドメインで使っている会社のPCで遅くなる原因は。。。

  1. cygwinを 1.7.35 以降の最近のバージョンにする (古いのは遅い)
  2. DNSのIPアドレスが間違っていると、長い待ちがおこる
  3. ドメインじゃないなら、 /etc/passwd と /etc/group を消すと良いかも(知れない)
  4. ドメインなら、ドメインコントローラの返事が遅いのかも
    • その場合、passwd/group をキャッシュして高速化できる
    • cygserverでドメンインキャッシュサーバをたててみても良いぞ
    • そもそもドメインにアクセスするの辞めちゃえば? (ADが更新しても知らんけど)
  5. それでもダメならデバッグモードで起動してみな
  6. ひょっとして ‘//c’ とか書いてない?

DNSが関係しているのは分かっていたけど、 会社のドメインコントローラが遅いとは疑っていなかった。 Windowsでは困ったことないし。

でもやってみよう。

まずはバージョン確認

以下のどちらかで確認できる。

uname -a
cygcheck -c cygwin

2.2.0 だったので、問題なし。

/etc/passwd と /etc/group の削除

cygwinでドメインに関係するような事はしないし、 むしろ悪さしそうなので、まず削除して様子をみてみた。

数時間使ってみて、酷いフリーズは経験しなかったけれど、 プチフリーズが解決したかと言うと、ちょっと分からない。

AD情報のキャッシュ化

ドメインの情報を削除するのも危険な気がしたので、 一応キャッシュしておいて、様子をみてみた。

ドメイン情報のキャッシュは、こうしてとれる。

getent passwd $(id -u) > /etc/passwd
getent group $(id -G) > /etc/group

その後、 /etc/nsswitch.conf を編集して、 ADにアクセスするより先にキャッシュ(files)を見るように変更する。

passwd: files db
group:  files db

正直、これも良くなったのか悪くなったのか分からない。

そもそもドメイン情報を使わないようにする

いくつか試してみた結果、 /etc/passwd と /etc/group を削除してしまうことにした。

実はこの状態でも、ドメインでアクセス管理しているネットワークサーバの ファイルにアクセスできたのだった。しかも今迄よりもサクサクと。(汗)

まだ、たまにフリーズはするものの (キャッシュはあった方が良いのかも知れない)、 全体的にファイルアクセスが軽快になった。

無くて良いものは、無い方が良い。 この状態で、またしばらく使ってみようと思う。