2024/04/12(金)RubyのHttpClientはそろそろ捨てるべき?

Rubyのhttpclient
GitHub - nahi/httpclient: 'httpclient' gives something like the functionality of libwww-perl (LWP) in Ruby.
を使って作成していたスクレイピング的なスクリプトが動かなくなってしまった。

↓のようなエラーを吐く。
 SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate has expired) (OpenSSL::SSL::SSLError)
原因は、取得先のサーバーがSSL証明書をLet's Encryptに入れ替えたため。

httpclientはルート証明書がライブラリ内に同梱されており、最終更新が2015年。
Let's Encrypt系のルート証明書は未対応である。

ルート証明書がライブラリ同梱なのは今どきではないし、更新が止まっているのも痛い。
モンキーパッチがGitHub上にあるので、そちらでとりあえず対応可能。

Connection to Lets Encrypt secured server fails · Issue #445 · nahi/httpclient · GitHub
class HTTPClient
  alias original_initialize initialize

  def initialize(*args, &block)
    original_initialize(*args, &block)
    # Force use of the default system CA certs (instead of the 6 year old bundled ones)
    @session_manager&.ssl_config&.set_default_paths
  end
end
httpclientは投げ捨てて、httprbを使った方が良いかも。

GitHub - httprb/http: HTTP (The Gem! a.k.a. http.rb) - a fast Ruby HTTP client with a chainable API, streaming support, and timeouts

パパっと書き換えたけど素直でかなり簡単に修正できた。
パフォーマンスも良いらしい。

なお、rubyのhttpclientでletsencryptの証明書を保有するサイトに接続できなくなった | 元祖ワシ的日記のやり方だと、Windows環境では上手くいったのだが、debian Linuxだと上手くいかなかった。
追求していない。

2024/02/23(金)Ruby XMLRPCでdokuwikiのAPIをコールするとエラー

最近機会があってdokuwikiを触っている。
DBを使わないので遅いが、その分設置場所の選択肢が多い。
PHPが使えるフリーサーバーがいくつかあるので、小さいチーム作業や情報公開用途であれば扱いやすいと思う。

さて、dokuwikiは標準でXML-RPCによるAPIを備えているのだが、Rubyからコールしようとしてハマった。

このサンプル通り、
xmlrpc:clients:devel:xmlrpc:clients [DokuWiki]
require 'xmlrpc/client'

server = XMLRPC::Client.new("localhost", "/dokuwiki/lib/exe/xmlrpc.php", 8084)
result = server.call("dokuwiki.getVersion")
pp result
としてコールしても、
XML-RPC server accepts XML requests only.
が返ってきてしまう。

環境は、
・dokuwiki: Release 2024-02-06a "Kaos"
・PHP: 7.4
・Ruby: 2.7
HTTPサーバは問わない。

調査。

・RubyのXMLRPCはリクエストのContent-Typeに"text/xml;charset=UTF-8"がセットされる。
・dokuwikiのXML-RPC APIは"application/xml"か"text/xml"だけを受け付ける。これはcharsetがあるのもダメっぽい?

うーん、リクエストにcharsetはあっても良いはずなので、dokuwiki側のコードがかなり変か何かを読み飛ばしてるかもしれない。

とりあえず、RubyのXMLRPCはhttp_header_extraをセットすることでヘッダーを上書きできる。
コレを使って、以下にすれば動く。
require 'xmlrpc/client'

server = XMLRPC::Client.new("localhost", "/dokuwiki/lib/exe/xmlrpc.php", 8084)
server.http_header_extra = {"Content-Type" => "text/xml"}
result = server.call("dokuwiki.getVersion")
pp result

2022/06/20(月)久々にプログラミングフォント調べた

最近良いプログラミングフォントが色々でてきているようなのでさらってみた。

2013年後半のプログラミングフォント事情 - 色々日記(ざ・めも)
以来。

今回の結論は、
・Ricty(もしくはRicty Diminished)使って不満がなければRicty
・Rictyのアンチエイリアスに不満がある場合は、PlemolJP
となった。

ただ、PlemolJP作者のフォントとはどれも素晴らしく、
HackGen
PlemolJP
Firge
UDEV Gothic JPDOC
の4つについては合うものを選べば良いと思う。

状況変化した内容をつらつら書いていく。

■Windowsのレンダリング
Win10になったときかWin10内でのupdateかで標準アンチエイリアス~ClearTypeがある程度改善したように感じる。
加えて高解像度モニタの普及とDirectWrite周りを調整できるソフトが増えたことで、以前ほど不満に感じるシーンが減った。

ただ、やはりまだWindowsのレンダリングはいまいちだと思う。

■フォント
ここ3年くらいで、ライセンスがゆるく品質の良いフォントが公開されている。
Google Fontsがハブになっているようだ。

・源ノ角ゴシック(Source Han Sans or Noto Sans)
・IBM Plex Sans JP
・BIZ UDGothic

あたりが品質も高く収録文字も多そう。
特に、モリサワのBIZ UDGothicがOpen Font Licenseで追加されたのは衝撃だった。

源ノ角ゴシックは様々な派生フォント(源真, 源柔, 源暎, Nasu, ...)を生み出しているので、
BIZ UDGothicもそうなっていきそうで楽しみ。

CJKオール対応の更紗なんてのもあるし、なんとなく中国パワーにひきずられてCJK対応が進んだ感じがする。
合成フォントの選択肢がとても増えた。

RictyはRictyでヒンティング追加されたりして少し進化。

少なくともライセンス的にかなり黒かったMeiryoKEを選択しなければいけない状況はないと思う。
世のフォント作者に感謝。

FontLinkもソフト側でできるものも多いし(秀丸ですらできる!)、もうやらなくていいのではないか。

なお、ソフト側でフォント合成する場合もフォントの幅や高さの問題で下端・右端が切れるリスクがあるのは同じ。

■求めるフォント
選択肢が増えたので、贅沢な話だが自分のほしいフォントを整理。

[必須]
・等幅
・英数字は全角の1/2
・文字はしっかり分離していてほしい。特に<=, ==が合体しないでほしい(リガチャは論外)
・破断は最小限(Hackはgの線をかなり省略するがちょっと嫌)
・|は分離してほしくない
・iの下部の右曲がりは嫌(lの下部の右曲がりはOK。どちらでもあり)
・標準アンチエイリアス・アンチエイリアスなしいずれでも視認性が高い
・記号△▲▼■□○◎●・←↓↑→系は全角で描画されてほしい
・文字の下端・右端が欠けてほしくない(合成フォントでは切れがち)
・フォントサイズでの表示乱れは最小限(特にWindowsの場合10.5ptの鬼門がある)

[ベター]
・文字の区別は極力ついてほしい。特に1とlと|は極力。
・英数字・日本語を混ぜ書き前提。バランスに違和感がないと嬉しい
・全角と半角に同じ文字がある場合、できるだけ似たような字体でかつ全角・半角の判別がつくのが理想
・比較・演算記号-=*/<>はできるだけ上下中央に揃っていてほしい
・0はスラッシュのほうが嬉しいが、ドットも許容。Oとは区別がついてほしい。

まずRictyが頭に浮かぶ… いやもうドンピシャRictyなのだが、あやつはアンチエイリアスが今一つだった。
というわけでさらってみる。

■今回試したやつ
個人的趣味に合うかどうか。
めちゃくちゃ私見で判定。
△Firge: 若干-=<>の上下位置が一致しないのが気になる。全体的に文字を破線にしがち(gとか&とか)
✕HackGen: |が分かれるのが気になる。iの下部が右曲がりなのが好みでない。<=>がややくっついて見えるのが嫌。10.5ptアンチエイリアスなしだと(){}が対称に見えない
△PlemolJP: {}がかなり強い曲線で作られてる。ややばとぱ(濁点・半濁点)が見分けづらい。#が線切断表記。0がドット
△UDEV Gothic JPDOC: {}が上下対象でない。ややばとぱ(濁点・半濁点)が見分けづらい。英数字が縦長の印象。半角qで目が滑りやすい。4が少し気持ち悪い
△Ricty Diminished: アンチエイリアスがシビア。=とか横線がボケやすい。M+側も比較的アンチエイリアスに弱い。非アンチエイリアス、10.5ptのときにsなどの上部がInconsolataとかより汚い(上辺にドット?が出る)
✕M+ 1M: *が上付きなのが嫌。半角英数(特に数字)の幅が狭すぎる。9.5ptとかで数字の高さがズレる。
✕Migu 1M: M+と同様
✕Myrica M:  |が分かれるのが気になる。日本語がやや細い。{}が上下対象でない。10.5ptとかで全角jがiに見えたりする。他にも下端が切れる文字がある
✕源暎ゴシック M: *が上付きになるのが嫌。<=>が完全にくっついてしまう。
✕戸越等幅: 「ば」など濁音が見づらい。全体的に潰れてしまう傾向があり、調整ができてない気がする。
✕更紗Gothic: fixedを使用する。ややばとぱ(濁点・半濁点)が見分けづらい。*が上付きになる。■○などが半角。右端が切れる。更紗で使ってるIosevkaはカスタマイズできるらしく、可能性を感じる。
✕Roboto J: ヒンティングありの方を使ったほうが良さそう。(){}の見分けが付きづらい。日本語の上下が目立ってガタつく
✕Ocami: 記号系(→とか)が半角。ばとぱがみわけづらい。
✕Cica: 記号系(→とか)が半角
✕VLゴシック: サイズによって、=の上下の太さが一致しない。
✕utatane: ==がわずかに合体気味。アンチエイリアス下での英数字の視認性が今ひとつ。
✕源暎モノコード: アンチエイリアスなしで、線の太さに安定感がない。フォントサイズ変更していると、()の左右で幅が違っていたり、縦の線だけ太くなっていたり。9ptで==が合体する。
✕Nasu M:非アンチエイリアス10.5ptで ==が合体気味。非アンチエイリアス下での英数字の視認性が今ひとつ
✕源ノ角ゴシック Code JP: 非アンチエイリアスだと:と;、,と.の区別が厳しい。
Firge, HackGen, PlemolJP, UDEV Gothic JPDOCの作者さん同じなのすごいなー

この4つは不具合っぽい挙動をすることが少なく、非アンチエイリアス・アンチエイリアス問わず素直。

字形としては、
UDEV Gothic JPDOC
が一番趣味に合うけど、英数字が縦に長過ぎるのかコードを読むときに目が滑りやすい。

PlemolJPは0がスラッシュでないのだが、どんな用途でも70~80点ある感じ。

アンチエイリアス環境下に限ったら丸になるやつもたくさんありそう。
作る側(特にMacユーザ)からしたらそんなの気にしてるやついねーよって感じだと思う。

改めて思ったのは字形もだけど、フォントつくる人の腕に依るところが大きい。
HackGen作者たわら氏の仕事が素晴らしい気がするし、ソース公開されてるから自力でフォント作る気があるなら4フォントのスクリプト全部読めばある程度合成フォント作るときの課題理解も進みそう(作れるとは言ってない)。

今後もどんどんフォント出てきそうなので期待。

2018/11/23(金)PinterestでPINした画像をGoogleドライブに保存できるようにする

■やりたいこと
PinterestでPINした画像をローカルで閲覧したい。おおむね、お絵描きの参考用途。
・ブラウザ窓だと参考画像として扱いづらい
・貧弱な通信環境でも閲覧できる
・いちいちブラウザ開くのが面倒

やっぱりローカルでアクセスできた方が便利だよね。

■調査と課題
直接Pinterestからデータを引っ張ってくることもできるが、定期実行なり待受の仕組みを立てる必要がある。可用性を高く、一方でできるだけ手間や予算がかからない方法を検討したい。自前サーバがあるのでこれを使ってももちろん良いのだが、可用性であればやはりクラウドに軍配が上がる。(半ば興味本位で)極力クラウドサービスだけで構成することを目指す。

ストレージサービスは一般にローカル同期の仕組みを持っているため、Pinterestからストレージサービスに連携できれば要求が満たせそう。

Pinterestとローカルサービスを繋ぐ方法として、IFTTTなどの連携機能構築サービスが有る。まずはこれを調査した。おおむね、パーソナル用途で機能と使いやすさを両立しているのは2018/10現在下記3つくらい。

・IFTTT(Maker)
・Microsoft Flow
・Integromat

これら全てに、Pinterestインプット・Googleドライブアウトプットアダプタがあった。
なのでこれらを繋げばいいだけに思える。

しかし、いざ使ってみると画像ではなくhtmlファイルが連携される。
どれもPinterestが公式で提供したアダプタらしく、画像そのものを外部サービスに渡さない意図的な作りと思われる。

ちなみに、各サービスの比較としては、
▼機能性
Microsoft Flow > Integromat > IFTTT

▼簡便性
IFTTT > Integromat > Microsoft Flow

高機能な方が一見良さそうだが、この手のクリックアンドポイントロジック構築は高機能にするほど最終的にフローチャート作成サービスになってしまい見通しやメンテナンス性が怪しくなるという特性がある。
複雑なものを作ろうとするほど、どこかの境界でコードを自分で書いたほうが俯瞰性が良くなる。

IFTTTはINPUT(THIS)とOUTPUT(THAT)の接続だけしか選べないが、これくらいがちょうど良いように思う。見通しが悪くならない範囲で足すなら、出力を多数化(3つまでとか)、フィルタを一段、データ加工を簡単なもので1段くらいだろうか(その場合IFTTT以外のサービスないしMakerを選ぶことになる)。

いずれのサービスもコール回数に制限がある。
今回用途では1日10枚以内が目処。
上記に挙げた3つのフリープランでいずれも問題なさそうだった。

将来増えるか減るかなどの見通しは不明。

さて、結局以下のように構成した。

■実装
IFTTT⇒Google Apps Script(GAS)⇒Googleドライブ⇒ローカル(Googleドライブの連携機能)

・IFTTTからpinterestのurlをGASに渡す
・GAS内で、FetchしてPinterestのhtmlを取得
・簡単な正規表現マッチで画像URLおよび属性情報を取得
・画像をFetchしてGoogleドライブへ保存
・ファイル名はID+PINの詳細があればそれをファイル名とする
・第一階層のボード名をフォルダとしてそこに保存する

1) GASで下記スクリプトを作成。作成時に各種認証を要求されるので設定してやる。
function doPost(e) {
  // パラメータの取得
  var jsonString = e.postData.getDataAsString();
  var data = JSON.parse(jsonString);
  var pinUrl = data.pinUrl;
  var boardName = data.boardName;
  
  // フォルダ無ければ作成  
  var rootFolder = DriveApp.getRootFolder();
  var pinterestFolder = null;
  var targetFolder = null;
  var folderIterator = rootFolder.getFoldersByName('pinterest');

  if (folderIterator.hasNext()) {
    pinterestFolder = folderIterator.next();
  } else {
    pinterestFolder = rootDir.createFolder('pinterest');
  }

  targetFolder = pinterestFolder;

  // ボード名が取れていればサブフォルダとしてボードフォルダを作成
  if (boardName) {
    folderIterator = pinterestFolder.getFoldersByName(boardName);
    
    if (folderIterator.hasNext()) {
      targetFolder = folderIterator.next();
    } else {
      targetFolder = pinterestFolder.createFolder(boardName);
    }
  }
  
  // html解析処理
  var pinResponseText = UrlFetchApp.fetch(pinUrl).getContentText();
  var imageUrl = pinResponseText.match(/property="og:image".*content="([^"]*)"/)[1];
  // 128文字まで
  var description = pinResponseText.match(/img alt="([^"]*)"/)[1].substring(0, 128);
  
  var imageFilename = pinUrl.match(/[^\/]*$/)[0];
  
  // 画像取得処理
  var imageResponse = UrlFetchApp.fetch(imageUrl);

  // 拡張子は画像本体のContent-Typeから作成  
  var imageFilenameExt = imageResponse.getHeaders()["Content-Type"].match(/image\/([a-zA-Z]*)/)[1];
  if (imageFilenameExt == 'jpeg') {
    imageFilenameExt = 'jpg';
  }
  
  var imageBlob = imageResponse.getBlob().setName(imageFilename + ' - ' + description + '.' + imageFilenameExt);
  
  targetFolder.createFile(imageBlob);
  
}
IFTTTから呼び出せるようにWebアプリケーションとして公開してやる。


2) IFTTTで、Pinterestのオフィシャルアダプタを使いWebHookでGASに連携する。設定は以下。

▼THIS(INPUT)
Pinterest公式の"New Pin on your board"
Pick a board: "Any Board"

▼THAT(OUTPUT)
IFTTT公式の"Make a web request"
URL: https://script.google.com/macros/s/****/exec
Method: POST
Content Type (optional): application/json
Body (optional):
{"pinUrl":"{{PinURL}}", "boardName": "{{Board}}"}
以上で完成。かなりお手軽。

■まとめと使い勝手について
クラウド、フリープラン、更には認証情報をOAuthの世界で完結させたPinterest画像のローカル保存サービスが構築できた。
目標は達成でき、そこそこ便利に使っている。
ただ、PinterestからIFTTTへの発火に少しラグが有り、Googleドライブへの連携にもラグがあるためあまり即時連携という感じにはならない。

特性を理解して使用しつつ、どうしても即時で必要な場合はChromeの拡張などを利用してダウンロードすることにする。

■IFTTTについて
便利。機能を絞っているところが良い。
もちろん絞ってる分できないことがでてくる。
直感的に苦手なことはわかるので、あとは自分が使う上でどういったところでIFTTTで完結できないのか何を組み合わせればよいのかを今後確認していく。

■Google App Script(GAS)について
ロジックを作る必要があり、アウトプットがGoogle関係であればこれ一択。
Javascriptで大体何でもできるし、ドキュメントの必要十分さ、特に開発環境の素晴らしさはワンダフル。

現状無料で使えてるが、将来的に有料化or閉鎖しないかはちょっと心配。あとは制限。
作るときはフェッチの制限を忘れていたがやっぱりあるよね。
Google_Apps_Scriptの無料制限メモ
今回の内容だとURL Fetch 100MBが制限になりそう。
この仕組に限定すれば数百枚くらいは耐えるだろう。

AWSで相当するのは、Amazon API Gateway + Lambdaだろうか。
こいつらは本番運用には良いが、作って動かすまでのハードルが低くない。
こういったミニサービスや、使い捨てのテストAPIなどを作りたい場合GASのほうが向くように思う。


■今後の課題
サービスの選択・組み合わせを継続的に知識アプデするのと、GASがかなりawesomeだったのでできることを覚えたい。


■結論
最近のグルーサービスすげえね

2015/07/09(木)logbackでサイズローテートしない

logbackでログがファイルサイズでローテートしない問題。

Java1.7 + logback-1.1.3

条件は実行時間が短いバッチのようなプログラム。

もともと↓の記述にしていたのだが、ローテートしてくれなかった。
[logback.xml]
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>./logs/hoge.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
      <fileNamePattern>./logs/hoge.%i.log.zip</fileNamePattern>
      <minIndex>1</minIndex>
      <maxIndex>3</maxIndex>
    </rollingPolicy>
    
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
      <maxFileSize>5MB</maxFileSize>
    </triggeringPolicy>
    <encoder>
      <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger\(%F[%L]\) - %msg %n</pattern>
      <charset>Shift_JIS</charset>
    </encoder>
  </appender>
調べてみると、logbackのSizeBasedTriggeringPolicyはI/O負荷対策のためファイルサイズを毎度チェックしにいかない。デフォルトでは16回に1回であり、16回ログ出力して初めてサイズチェックに行く。ログ出力の頻度が多いと間隔を開け、頻度が少ないと間隔を狭める。

今回のプログラムは16回ログを出すフローがほとんどない。実行時間も短いため、間隔調整の恩恵も受ける暇がない。親切ではあるのだが、プロセス内の初回はチェックするなど対策が必要に思う。

このプログラムごく短時間で起動->終了し、ログの出力回数・起動頻度とも高くない。毎回チェックとしたい。

[logback.xml]
    <triggeringPolicy class="foo.bar.CustomSizeBasedTriggeringPolicy">
[カスタムクラス]
package foo.bar;

import java.io.File;

import ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy;
import ch.qos.logback.core.util.FileSize;

public class CustomSizeBasedTriggeringPolicy<E> extends SizeBasedTriggeringPolicy<E> {

	String maxFileSizeAsString = Long.toString(DEFAULT_MAX_FILE_SIZE);
	FileSize maxFileSize;

	public CustomSizeBasedTriggeringPolicy() {
	}

	public CustomSizeBasedTriggeringPolicy(final String maxFileSize) {
		setMaxFileSize(maxFileSize);
	}

	@Override
	public boolean isTriggeringEvent(final File activeFile, final E event) {
		//オリジナルのisTriggeringEventでは発火しないことがあるため、ログ書き出しごとにチェックする
		return (activeFile.length() >= maxFileSize.getSize());
	}

	@Override
	public String getMaxFileSize() {
		return maxFileSizeAsString;
	}

	@Override
	public void setMaxFileSize(String maxFileSize) {
		this.maxFileSizeAsString = maxFileSize;
		this.maxFileSize = FileSize.valueOf(maxFileSize);
	}
}
isTriggeringEventだけいじったクラスを作成してやって、logback.xmlでそちらを見るようにしてやる。

とりあえずこれで動くことは動く。

2015/07/09(木)LogbackでプロセスIDを出力

logbackでプロセスIDを出す方法。

Java1.7 + logback-1.1.3

あまりいい方法が見つからなかったが、とりあえず出りゃいいやまではできた。

起動コマンドなりスクリプトなりがいじれるのなら、SystemProperty経由で設定・取得する方法が使える。

[起動コマンド]
exec java -Dpid=$$ -jar /foo/bar.jar
[logback.xml]
<pattern>%d{yyyy/MM/dd HH:mm:ss} [${pid}] %level %msg%n</pattern>
-Dpid=$$で、プロパティ:pidにプロセスIDをセット、patternに${pid}と記述してやるとlobackの機能で出力できる。
もちろんUnix環境限定。

なお、シェル側のプロセスIDがほしい場合は、execを外し直接javaコマンドをたたく。
java -Dpid=$$ -jar /foo/bar.jar
Webアプリケーションで動いている場合は、何がしかプロセスIDに相当するものがSystemPropertyにいると思うので${}でそれを拾えばいい(はず)。

本当なら、ManagementFactory.getRuntimeMXBean()で取得するのが正解のようだが、その場合PatternLayoutをカスタムしてコンバータをいじって… とやらなければいけない気がする。規模によってはさすがに大仰か。

[参考]
Igor Minar's Blog: How a Java Application Can Discover its Process ID (PID)

2014/08/12(火)TOMCAT + logbackで、logback.xmlを外出し

アプリケーションサーバ:TOMCAT、ログライブラリ:logbackの組み合わせで、
logback.xmlをwarの外に追い出そうとしたらプチハマリしたメモ。

環境は、
TOMCAT 7.0.54.0
logback 1.1.2

一応できた。ただし、すっきりとは書けない。

Context定義にVirtualWebappLoaderを追加する。
たとえば、WEB-INF以下にlogback.xmlを置いた場合以下のようになる。
<Context>
  <Loader
    className="org.apache.catalina.loader.VirtualWebappLoader"
    virtualClasspath="C:/foo/bar/WEB-INF"
  />
<Context/>
ここで注意。
必要なのがlogback.xmlだけの場合、ファイル名まで書いてやりたいので次のようにしがち。
    virtualClasspath="C:\foo\bar\WEB-INF\logback.xml"
しかしこの場合、VirtualWebappLoader側はlogback.xmlを認識するが、logbackがlogback.xmlを読みにいかない模様。
あくまでディレクトリパスを書く必要がある。

絶対パスなのがいまいちな場合、$tomcat.base or $tomcat.homeが使えるのでそれを使ってなんとか相対パスで書く。
(tomcat.home->catalina.homeかもしれないのでRTFM)。
    virtualClasspath="${tomcat.home}/webapps/foo/bar/WEB-INF"
このどっちもいまいちだと難しい。TOMCATではほかの手が見つからなかった。
アプリケーションサーバを切り替えたほうがいいかもしれない。

アプリケーションルート的な所から相対パスでアクセスしたいという要望はあると思う。

あとはメモ。
virtualClasspathの書き方としては、Windows環境下ではディレクトリ区切り子は"/"でも"\"でもよい。
ディレクトリパス指定時は末尾の区切りはいらない。

Context周りの仕様で怪しいところがあるなら本家ドキュメントで確認。Apache Tomcat 7 Configuration Reference (7.0.55) - The Context Container

Eclipseからプラグイン経由で使う場合、さらにいろいろ留意。

Eclipse+Tomcat Pluginでコンテキスト定義に追加する場合、プロジェクトのプロパティ->Tomcat->全般->その他の情報にLoaderセクションをべたっと貼り付けて、プロジェクト->右クリック->"コンテキスト定義を更新"でよい。

コンテキスト定義をMETA-INF/context.xmlなどで作っていても、現在のEclipseのTomcatプラグインは拾う機能がなさそう。コンテキスト定義更新で%CATALINA_BASE%/conf以下に反映されていないことに注意。META-INF側はconfより優先順位が低く参照されない。


こっから下はおまけ。
動作確認時に%CATALINA_HOME%/conf/logging.propertiesに、ログ出力を追加してTOMCATにログをはかせるようにした。
org.apache.catalina.loader.VirtualWebappLoader.level = ALL
org.apache.catalina.loader.VirtualWebappLoader.directory = ${catalina.base}/logs
なお、Eclipseから起動したTOMCATはcatalina.*.logとかははかないので注意。
ここら辺は"eclipse, tomcat, ログ"とかで検索してほしい。

2014/02/26(水)Ruby 1.9以降のirbでBackspaceで表示が崩れる

Ruby1.9以降(mswin32版)のirbで、Backspaceでの削除時に表示が崩れる問題。

環境はWindows7(64bit)。

消そうとした文字の1文字手前が消えたり、カーソルがプロンプトにめり込んだりとなかなかに怪しい。

画面にフラッシュされるのも数秒程度の遅延がある場合がある。

内部データは正常、あくまで表示が崩れているだけのようだが煩わしいので直したい。

下参照。

ruby - Backspace and arrow keys aren't working in IRB(Git Bash console) on windows machine - Stack Overflow

とりあえずirbで使用しているreadlineライブラリ周りに問題があるのは間違いない。

--noreadlineオプションを使えば問題は解消するが、Up-Keyでのhistory等は効かなくなる。

mingw32版ではこの問題はない。[2014/03/31 下に追記した]
なんだかめんどくさいなあ。

[2014/03/31追記 ここから]
と上では書いたが、mingw32版でも遅延があった。

irbについては、--noreadlineであっても何か1文字入力すればUp-Keyでhistoryが動くようだ。これでいいことにする。

Windowsの Users\<ユーザ名>以下に設定ファイルを置いてやって、irbはreadline不使用をデフォルトにする。

Users\<ユーザ名>\.irbrc
IRB.conf[:USE_READLINE] = false
ついでに、pryも同様の問題を抱えてるので直したい。
が、pryには--noreadlineオプションがない模様。
しゃーないのでコンフィグを怪しげにいじる。

[参考]
Changing Pry.config.input makes the prompt disappear · Issue #821 · pry/pry · GitHub

pry.config.inputをSTDINに差し替えるとreadlineが外せるらしい。
ただし、これをするとプロンプトを自前で表示しないといけない。

以下を参考に、
Rubyistよ、irbを捨ててPryを使おう - TIM Labs

Users\<ユーザ名>\.pryrc
Pry.config.input = STDIN
Pry.config.output = STDOUT

Pry.config.prompt = [
  proc {|target_self, nest_level, pry|
    nested = (nest_level.zero?) ? '' : ":#{nest_level}" 
    prompt = "[#{pry.input_array.size}] #{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}(#{Pry.view_clip(target_self)})#{nested}> "
    print prompt
    prompt
  },
  proc {|target_self, nest_level, pry|
    nested = (nest_level.zero?) ?  '' : ":#{nest_level}"
    prompt = "[#{pry.input_array.size}] #{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}(#{Pry.view_clip(target_self)})#{nested}* "
    print prompt
    prompt
  }
]
promptの表示を追加。
プロンプト内容はお好みで。
Pry.config.output = STDOUT行が必要かはちゃんと判断していない。

このやり方では入力後に改行が重複出力される問題がある。
また、起動直後にプロンプトがwarningなどと重なるので1回Enterしないといけない。
個人的には許容範囲内だが気になる人は気になるかも。

pry初心者なので、pryの全機能が不足なく動くかは確認していない。
なお、ターミナル上での日本語文字化けが改善するケースがある(追求していない)。

さて、readline周りの挙動は悩ましい。自分でコンパイルすれば直りそうなのだが、やりたくないなあ… やるんだったら配布までやらなきゃだと思うので。
[2014/03/31追記 ここまで]

さて、--noreadlineオプションは記憶しておくとして、Windowsに入れているRubyの措置について考える。

・mswin32版 -> mingw32版にする?
する。PATH環境変数と、スクリプト起動用のexeパスを書き換えた。

とりあえず、mingw32を避けてるのも変なので使ってみるというのが一つ。

mingw32版はcygwin版のようにcygwin周りのファイルが必要ということはないので、mswin32版とほぼ同じように使っていける(はず)。2.1.0が来てないあたり、若干保守的な様子。高速化はmingw32版の方が効いているとのこと。

mswin32版はgemでコンパイルをかけるような場合ではどうもトラブりやすい。pryにしろ、atomicにしろ自分の腕ではgem installに失敗したし、これを打開するためのコストをかけるほどの余裕がない。exerbとかが標準梱包なのは有り難く、gemで追加しない分にはこちらの方が便利か。オフィスでオフラインで使用する場合などではmswin32版の方がうれしいかも。DXRubyが入ってるのも楽しい。

・CP932なrubyスクリプトのエンコードをUTF-8に変える?
変えない。今回は断念して、マジックコメントでWindows-31J指定が入ってないものには追加。

動いてるスクリプトが、コマンドラインから日本語を含むファイル名を受け取って動くようなものが多いため、テストに時間がかかるというのが一つ。

Windowsのファイル名を扱う以上どうしてもSJISで処理したほうが楽だというのも間違いはない。今後UTF-8混じりのファイル名などでバグが起きない限り、既存のスクリプトはこのままにしておいて新規作成分はUTF-8で作ることにする。

2014/01/18(土)Rubyでtwitterライブラリを動かすまでのあれこれ

環境はWindows7(64bit)。

各所にやり方はまとまっているのだが、ここしばらくのTwitterの仕様変更やRuby特有のwinケアの甘さでちょいハマリしたのでメモ。

なお、gem installの項でmswin32版(ActiveScriptRuby 1.8~2.1全て)は環境構築できなかったので、minGW版 2.0.0の話になる。

gem install twitter周り

gem install twitterが通らない。依存で入ってくる"atomic-1.1.14"パッケージが鬼門の模様。
atomic_reference.c(75) : fatal error C1189: #error :  No CAS operation available for this platform
このエラーで止まる。

mswin32版では結局打開できず。

minGW版で打開できた。
どうやらコンパイラ=gccかつgcc4.8.1以降でないとソース変更なしではコンパイルできないらしい。以下参照。
failed compile with atomic-1.1.14.gem · Issue #32 · headius/ruby-atomic · GitHub

バイナリを集める。

RubyInstaller for Windows
minGW版Ruby最新の2.0.0-p353+DevKit-mingw64-32-4.7.2-20130224-1151を取ってくる。

MinGW | Minimalist GNU for Windows
gccはDevkitの4.7.2では×。MinGWを別に入れてgcc 4.8.1を取ってくる。

以下2箇所にパスを通す。
MinGW\bin
MinGW\msys\1.0\bin

dk.rb init, dk.rb installを終えた後に、
Ruby200\lib\ruby\site_ruby\devkit.rb
を書き換える。
$ diff devkit.rb.orig devkit.rb
10d9
<   ENV['PATH'] = 'C:\\online\\Ruby200\\devkit\\bin;C:\\online\\Ruby200\\devkit\\mingw\\bin;' + ENV['PATH']
devkit内のPATH追加を削っただけ。

これでgem install twitterが通るようになった。

token取得

RubyでTwitterのapiを使ってみる - D-ramu blog
twitter側にアプリを登録するまでは上記参照。

自分の環境ではget-twitter-oauth-tokenは上手く動かなかったので、tokenは以下のやり方で取得した。
RubyでTwitterのOAuth認証のアクセストークンを得る手順 - Qiita [キータ]

ssl周り

いざアクセスしようとすると、sslでエラー。
c:/online/Ruby200/lib/ruby/gems/2.0.0/gems/twitter-5.5.1/lib/twitter/rest/client.rb:143:in `rescue in request': SSL_connect returned=1 errno=0 state=SSLv3 read
server certificate B: certificate verify failed (Twitter::Error)
証明書がRubyから見えてないですね。
以下を参考に設置。
igaiga diary(2013-06-17)

api周り

twitterライブラリの仕様もちょくちょく変わってるので注意。

3分でスッキリ! Oauth 1.0図解とRuby Twitter bot開発 | KumanBlog

よく見かけるドキュメントと、configへのアクセスやconfig内のkey名が変わってる。

RTFM。
File: README ― Documentation for twitter (5.5.1)

2014/01/16(木)clは環境変数PATHからインクルードファイルを探さない

メモだけ。

環境はWindows7(64bit), mswin32版Ruby 1.8(ActiveScriptRuby)。

gemで要コンパイルのライブラリ入れるときにコンパイルに失敗する。
c:\online\ruby\lib\ruby\1.8\i386-mswin32\win32/win32.h(31) : fatal error C1083: include ファイルを開けません。'windows.h': No such file or directory
NMAKE : fatal error U1077: 'C:\Windows\system32\cmd.exe' : return code '0x2' Stop.
原因。mswin32版RubyはMS VC++をコンパイルに使用する。コンパイラCL.exeは環境変数"PATH"にINCLUDEファイルのディレクトリを記述していても見に行かない。

初歩的な話だが、ここんとこMS VC++コンパイラ触ってなかったのですっかり仕様を忘れていた。

対策は、環境変数INCLUDEに記述するか、/Iオプションで明記してやる。

gemの中いじるのめんどくさいので、eveで環境変数INCLUDEにディレクトリを追加した。

[参考]
/I (追加インクルード ディレクトリ)

そろそろbundler周りも覚えた方が良さそうだ。