【執筆報告】うぶんちゅ!まがじん ざっぱ〜ん♪ vol.8(ゲストページ)
ちょっと出遅れてしまいましたが、うぶまが*1の元執筆陣など豪華なメンツが書かれている同人誌「うぶんちゅ! まがじん ざっぱ〜ん♪」の最新号、vol.8のゲストページに記事を書かせてもらいました。
私が書いた内容は「国際イベントの招致を手伝ってみましたよ」ということで、openSUSE.Asia Summit 2017 Tokyoの舞台裏的な話。数百人規模の人員が集まってスポンサーがたくさんつく言語系カンファレンスについてだとけっこう巷に情報ありますけど、完全手弁当で小さいけど国際イベントってノウハウそんなに表に出てない気がして、そういうのまとめる場を提供してくださったTeam ZPNのいくやさんほか皆様には感謝感謝です。
私のことはおいておいても、よかぜさんのバイオニックで生物で白衣なビーパーおねえさんの表紙も素敵ですし、面白い記事が満載で、目次を引き写すと:
- 表紙: よかぜ
- Ubuntuではじめる楽しいゼミ運営: おしえたかし
- ポメラDM200にUbuntuをインストールする: 柴田充也
- Boomagaを使ってPDFを小冊子印刷する方法: あわしろいくや
- NanoPi NEOで作成するテレビ視聴環境: ryunuda
- いつでも始められるmpv: kazken3
- らくごうさんちのノートPC事情: Rakugou
- Ubuntuで心理学実験: はにゅう
- 国際イベントの招致を手伝ってみましたよ(ゲストページ): おがさわらなるひこ
- 技術書典4で冊子版『ざっクリわかる Ubuntu 18.04 LTS 』を頒布できなかった顛末(ゲストページ): いくや
個人的な趣味嗜好としては、おしえさんのゼミ運営の話(Mattermostでゼミ内コミュニケーション、いいですね)、いくやさんのBoomagaネタが特に面白かったです。もひとついくやさんのゲストページは涙涙の内容でございました。はにゅうさんの心理学実験の記事も、自分とはちょっと違う世界の話でよかったです*2。
捨て記事なしの内容でこれが700円は安いと思うんだな。ということで、みなさまぜひに。購入サイト:Gumroad BOOTH
【執筆報告】日経Linux 2018年7月号 & 日経xTECH LibreOffice Kaigiレポート
たまには執筆報告など。報告がたまというわけじゃなくて、執筆のお話がそんなにあるわけじゃない(手持ちのコマ少ないですからね、わたくし……)ってことです。
日経Linux 2018年7月号にちろっと1ページ、LibreOffice 6.0のレポート記事を書きました。
何度も何度も何度も同じこと書きますがLibreOffice 3系とか4系とか5系とか6系ってバージョンはなくて、6.0でメジャーバージョンなんですよね。で、なんで5.4から6.0になったの?というと、はっきりとブランディングですよと断言してしまいました。LOOLとかもそうだししばらくご無沙汰なモバイル版とかもそうだけど、これからいろんな取り組みしてくからよろしくってことですね。
で、超豪華付録「Ubuntu 18.04 LTS 日本語 Remix 使い方が全部分かる本」にも、ありがたーーーーいことにお声がけいただきまして、ドライバーレス印刷についての記事を加筆修正して再録していただきました。前に書いたときに書きすぎて盛大にボツになった内容も、これを機に復活することができました。
記事にも書いたとおり18.04 LTSからドライバーレス印刷で自動生成されるPPDが言語設定を反映するようになったのですが、これが盛大にバグっており、バグレポしたんですけど見事にスルーされておるな……ふむ。Upstreamにレポートしたほうがいいのかなあ。
私の記事はともかくめちゃくちゃ力の入った別冊なのでUbuntuユーザーは買って損はないです。Ubuntuユーザーじゃない人も買いましょう。
ついでというわけではないですが、先日行われましたLibreOffice Kaigi 2018(ご参加いただいた皆様、ありがとうございます!)のレポートを日経xTECHさんに掲載いただきました。FacebookとかTwitterでは告知しましたけど。
よかったら読んでくださいませ。あなたのクリックが、次のレポート掲載の助けになるのです。はい。
BrowserMob Proxyを用いて認証プロキシありの環境下でSeleniumによるChrome自動操作を行う
みなさん、認証プロキシはお好きですか?
私はもちろん嫌いです。が、まあそういう環境がまだまだ多数あるということも知っておりますし諸事情を考えるとやむを得ないこともあるのかなーとは思います。
そういうところでSeleniumによるGUI自動操作を行いたいというニーズがありまして……Google先生に聞いてみるといくつか答えが得られるのです。が、仕様変更があったり条件がちょっと違ったりとかしてうまくいかない。しばらく煮詰まっていたのですが、うまくいったのでご紹介。
結論としては:
を使ってこんなコードで良さそうです*1。事前に次のような変数は初期化されているものとします。
変数名 | 意味 |
---|---|
proxyServer |
プロキシのサーバー名 |
proxyPort |
プロキシのポート番号 |
username |
プロキシ認証ユーザー名 |
password |
プロキシ認証パスワード |
// BrowserMob Proxyにて、認証プロキシにチェーンするプロキシを作成する // 参考: // https://github.com/lightbody/browsermob-proxy/blob/master/browsermob-core/src/test/groovy/net/lightbody/bmp/proxy/ChainedProxyAuthTest.groovy BrowserMobProxy bmp = new BrowserMobProxyServer(); // Don't use InetSocketAddress.unresolved(), use new InetSocketAddress instead bmp.setChainedProxy(new InetSocketAddress(proxyServer, proxyPort)); bmp.chainedProxyAuthorization(username, password, AuthType.BASIC); bmp.setTrustAllServers(true); bmp.start(); // 動作しているプロキシをSeleniumのProxyクラスに変換して登録 Proxy proxy = ClientUtil.createSeleniumProxy(bmp); proxy.setNoProxy("localhost"); // Proxy除外設定もかける DesiredCapabilities cap = new DesiredCapabilities(); cap.setCapability(CapabilityType.PROXY, proxy); System.setProperty("webdriver.chrome.driver", "./driver/linux/chromedriver"); WebDriver driver = new ChromeDriver(cap); // 古いスタイルだというのは知っております……。 driver.get("http://www.google.com"); // サンプル // ここにいろんな操作を書く driver.quit(); bmp.stop();
探し方が良くないのかもしれないのですがBrowserMob ProxyのEmbeddedモード(Javaのコード内でライブラリとして利用する方法)がなんかいい情報がなくて、あーでもないこーでもないと試行錯誤していたのですが、コード片上にコメントで書いてあるとおり ChainedProxyAuthTest.groovy
っていうズバリのテストコードがあって、それを参考にしました。
BrowserMobProxy.setChainedProxy()
に渡すための InetSocketAddress
をどうやって生成するかについては、BrowserMob Proxyの過去のIssueに答えがありました*2。
枝葉ですが、私自身はSeleniumのラッパークラスであるSelenideを使ってるので、このときのプロキシ設定は DesiredCapabilities
を使う代わりに WebDriverRunner.setProxy()
すればうまくいきます。
試行錯誤の内容
- 「自動テストスクリプトからは認証なしプロキシとして見えて、実際の認証プロキシにチェーンしてそちらに認証情報を渡す」小さなプロキシ(以下チェーンプロキシ)を立てるって方法が複数ヒットする。たしかにうまく行くのはわかるけど、いろいろあってすごくやりにくいのでこの方式は「どうしようもない場合の切り札」として検討後回し。
- Seleniumの
Proxy.setSocksUsername()
/Proxy.setSocksPassword()
を使えるって情報が複数ヒットするも、正しく動作せず。まあSocksって名前だしねえ……。もしかしたらプロキシ認証がBasic認証じゃない場合は通ったりするのかしら。 - Chromeには
--proxy-auth
ってコマンドライン引数がある……という情報があったが、指定しても無視されるし、頼りのList of Chromium Command Line Switches にはそんなオプションはない。廃止された? - 環境変数
http_proxy
で指定すれば……という意見もあったけど、今回、操作したい対象そのものはプロキシの中にあって、そこから呼ばれてるJSとかCSSが外部……という状態なので除外設定が必要。環境変数だとそういう制御ができない気がして、そっち側の調査はあまり深堀してない。 - 手詰まりなのでSeleniumHQのSlackで聞いてみたところ、……Seleniumはそういう機能ないのでBrowserMob Proxyを使うといいよと助言をもらう。
- ふむふむと調べると……。テンパっていた中で超斜め読みして、うーんこれは結局チェーンプロキシを立てる話なのでは、と誤読して、ちゃんと調べるのは後回しにした。
- 色々忙しくしてたら本件納期が差し迫っているのに解決のめど立ってなくてやばい。そんなわけでナナメ読みしたドキュメントを少し丁寧に読んだら、BrowserMob Proxyにはプロセスとして動作するモードとJava埋め込みできるモードがあって、後者ならプロセス別立て要らないのかも? しかも「Using with Selenium」なんて項目もあるし。ちょっと期待。
- ざくっと調査すると次の記事がヒット。この記事のコード例は今のBrowserMob Proxyだとまったく通らない*3けど、やりたいことはできるようなので真面目に書き方を調べる。
- ドキュメントを読んでもいまいち使い方わかんないしGoogleで探してもずばりのページはないなあ……というかJavaDocとかはないのか、と思って調べたけど、考えてみればソース読めばいいんだよね。ということで読む。
- というかソース読んでるぐらいならテスト見れば使い方わかるんじゃね? と思って、
src/test
以下を探したら正解! - 真面目に調べ始めてからコードをいじってあーでもないこーでもないってしてた時間はそんなには長くないかな。2〜3時間? 返す返すもテンパってたときにドキュメントをちゃんと読まなかったのが悔しい。
- コード書くよりめんどくさかった作業は、検証用に手元に認証プロキシがある環境を作ることでした。結局 GitHub - sameersbn/docker-squid: Dockerfile to create a Docker container image for Squid proxy server こいつを使って、
/etc/squid3/squid.conf
はホストにマウントして認証設定書いて、/etc/squid3/.htpasswd
はめんどくさかったのでコンテナ内部に直接作っちゃいましたが、これもホストにマウントすればよかったんだな。この話も気が向いたら書きます。
- コード書くよりめんどくさかった作業は、検証用に手元に認証プロキシがある環境を作ることでした。結局 GitHub - sameersbn/docker-squid: Dockerfile to create a Docker container image for Squid proxy server こいつを使って、
あとから考えるとBrowserMob ProxyをSeleniumから使うことについては:
定番のこの本に書いてあるので、もっと早く気づいてもよかった。BrowserMob Proxyはパフォーマンス測定とかにも使うやつなので、あんまり印象に残ってなかったんですよね(いいわけ)。
(メモ)Jenkins/GitLabをお試しする環境をDockerで構築する
最近、JenkinsとGitLabの連携機能とか、Jenkins Blue Oceanを試したりしています*1。 で、検証環境を手元にほしいのですが、GitLabの構築めんどくさそうだったので、Dockerだったら楽なんじゃないかなという*2。 docker-composeとかを使うところなのかもしれないですが、素朴なので手でコマンドを叩いてやってみました。
便利だったのでメモ。今更感アリアリですが。
ネットワークの作成
今回二つのコンテナを準備してそれぞれを名前解決したいわけですが、そのためにはネットワークを作るといいらしい。
参考:
ふむふむ、やってみましょう。
% docker network create --driver bridge gitlab 【ID文字列】 % docker network inspect gitlab [ { "Name": "gitlab", "Id": "【ID文字列】", "Created": "2017-12-20T05:45:30.1592604Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.18.0.0/16", "Gateway": "172.18.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": {}, "Labels": {} } ]
Jenkinsの起動
さっき作ったネットワーク gitlab
を使って構築するようにします。コンテナ内の /var/lib/jenkins
はコマンド実行時のディレクトリ直下の jenkins-master
というディレクトリにマウントするようにしました。コマンドは公式ドキュメントを参照。
-name
で名前つけてあげないと、コンテナ間の名前解決できないようなので。
docker run --detach -p 8080:8080 -p 50000:50000 -v `pwd`/jenkins-master:/var/jenkins_home --name jenkins --net=gitlab jenkins/jenkins:lts
GitLabの起動
こっちも公式ドキュメントを参照。
docker run --detach \ --hostname gitlab.example.com \ --publish 443:443 --publish 10080:80 --publish 10022:22 \ --name gitlab \ --restart always \ --volume `pwd`/gitlab/config:/etc/gitlab \ --volume `pwd`/gitlab/logs:/var/log/gitlab \ --volume `pwd`/gitlab/data:/var/opt/gitlab \ --net=gitlab \ gitlab/gitlab-ce:latest
接続確認
手抜きで片方向だけ。
docker exec -it jenkins /bin/bash jenkins@3c121fdb1b14:/$ ping gitlab PING gitlab (172.18.0.3): 56 data bytes 64 bytes from 172.18.0.3: icmp_seq=0 ttl=64 time=0.386 ms 64 bytes from 172.18.0.3: icmp_seq=1 ttl=64 time=0.122 ms ^C--- gitlab ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.122/0.254/0.386/0.132 ms jenkins@3c121fdb1b14:/$ exit
いけてますね。
GitLabの外部名変更
http://gitlab
になってればいいらしいので。
% docker exec -it gitlab /bin/bash root@gitlab:/# vi /etc/gitlab/gitlab.rb (編集) root@gitlab:/# exit
## GitLab URL ##! URL on which GitLab will be reachable. ##! For more details on configuring external_url see: ##! https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab external_url 'http://gitlab'
こんな感じで書き換えて docker restart
すればうまくいきました。
Jenkins側の名前設定
こちらはGUIでポチポチ変えるだけ。[Jenkinsの管理] > [システムの設定] > [Jenkinsの位置] にて http://jenkins:8080
にします。「リバースプロキシの設定がおかしいようです」と言われますが無視して大丈夫です。
できた!
JenkinsにGitLabプラグイン入れて簡単な設定をしてみたらちゃんと二つのコンテナ間でやりとりできているようです。
ホストマシンをうっかりリブートしてコンテナが止まっていても docker restart
すればさくっと再起動するので楽です。
ただ、手元の環境だとコンテナ2個上げるとホストマシン側が目に見えて遅くなるのが少し困りどころですね。まあ、我慢できなくはないですけど。
執筆報告: 日経Linux 2018年1月号
お声がけいただきまして、日経Linux 2018年1月号 特集1「大幅刷新!始めるなら今 新しいUbuntu完全ガイド」に記事を書きました。12月8日発売。
(上のリンクはアフィなので、踏みたくない人は自分で適当に検索してくださいませ)
この特集自体は読者として読んでもとっても面白いのですが、その中の1ページ……具体的にどこかってのはこのブログをお読みのかたは想像できるのではないかな……プリンターとスキャナについてですえ、を担当させていただきましたです。
筆者の役得としては、才人揃いのUbuntu Japanese Teamの皆さんに混ぜてもらって、その原稿やらゲラやらを先行してみられるというのがあって、いやーみなさん題材の選定から技術的な誠実さから最終的な読み物としての完成度も面白さ本当にすごいなあって思います(小学生みたいな文章ですみません)。その中に交じるのはプレッシャーもありますけどとてもハッピーです。私としては。
相変わらず字数数えられないやつで盛大にはみ出たのですが、そのはみ出た部分についてはまたいずれ。具体的には、ドライバーレス印刷対応の機種だけど俺はベンダー製ドライバーを使いたいんじゃ! という人向けの記述が落ちてます。まあそこ調べが足りなかった(例えばHPLIP対応機種でどうするかとか)ので、別の機会になったほうがよかったですね。
あと、ニュース欄にopenSUSE.Asia Summit 2017 Tokyoのレポートも載ってますが、こちらの執筆もちょっと手伝いました。
ついでにもう一つ、一つ前の号にもLibreOffice 5.4についてのニュースを1ページ書いたのここでお知らせするの忘れてたので。LOOLについてもほんのちょっとですが触れました。
そんなわけで、ぜひ購入お願いします!
(小ネタ)LibreOfficeと笑顔
5日目*1。4日目は Arachansan さん(さんが重複)が書いてくださいましたありがたやありがたや。
今日もまた超小ネタです。
TDFのブログにて「LibreOffice Community Smiles」という連載が始まっております。コミュニティメンバーの素敵な笑顔の写真を毎日紹介するというもの。
- LibreOffice Community Smiles #1 - The Document Foundation Blog
- LibreOffice Community Smiles #2 - The Document Foundation Blog
- LibreOffice Community Smiles #3 - The Document Foundation Blog
みんないい表情!
LibreOfficeコミュニティはそんなに大きくないこともあって家族的だとぼくは思うのですが、それらしい連載だなあって思ってます。過去にTDFブログではAdvent Tipsとかアドベントカレンダー的な連載があったので、これもその一環なのかな。いろんな笑顔がみられると嬉しいですね!
明日はtokyrahさんです。よろしくお願いします!
*1:今日の夜予定があるので、ササッと書いて公開して、Adventarにリンク貼ろうとしたら、 nogajun さんが立候補していただいていました。それならそれでいいやと思ったのですがnogajunさんに気を使っていただいてずらしていただいたので。すみませんすみません。
LibreOfficeとCJK
三日目。昨日は@arachan@githubさんによる「Python odfpyでDrawファイルを弄る」でした。
さて、今日も小ネタです。
先日同じことを書きましたが、
The Document Foundationの「Next Decade Manifest」に、つぎのような表現があります。
私達の立場:
すべての人が、私たちのオフィススイートを母国語に翻訳し、母国語で文書化し、母国語でサポートし、母国語で普及ができるようにして、母国語の保護を支援します。
この立場に立って考えると、我々日本語話者が母語*4 である日本語でオフィスソフトを使うためには、単にUIが翻訳されているというだけではなく、日本語……それに限らず、中国・台湾・韓国……つまりCJKが正しく使えることが大事なのです。 ですが、自分自身の使っていない言語について「正しい」かどうかを判断することはとても難しいので、CJK文化圏で協力して、自分たちで不具合を直し、機能を正しく実装していくことが大事です。
って、この↑文章を読んだ人ならすでに読んでるとは思いますが、今年のLibreOffice ConferenceおよびLibreOffice mini-conference Japanで榎さんが本件についてまとめているので、そのスライドを読みましょう。
さくっとまとめれば、日本語についてはやっぱりユーザーも開発者も(世界的に)すくないので、不具合を見つけたら(開発者が目につくところで)表明する、不具合報告の切り分けに協力する、もしかしたら直すのに挑戦する、といったことです。
ということで、スライドからの抜粋に近い形ですが、参考情報のリンクを紹介します。今回はCJKに限った紹介ですので、CJKに限らないグローバルな開発やQAについての情報については省略します。
日本語の不具合について相談する日本語の場所
あんまりないんですよね。1日めのエントリーに書いたようにSNSでカジュアルに相談するのはテかもです。
メーリングリスト
メーリングリスト | LibreOffice - オフィススイートのルネサンス
The Document Foundationによってホストされているメーリングリストは、こういうお話をするのに公式的な場所です。
一般的に投稿可能なリストは users@ と discuss@ と二つありますが、両者の使い分けとしては:
- users@ - ユーザーとしての使い方などの情報交換
- discuss@ もう一歩踏み込んで、コミュニティに参画したいと思う方の議論の場。例えばLibreOfficeの日本語化についてなど。
今回のネタに関してで言えばどちらでもよいです。自分の立ち位置で好きな方を選んでください。Nabbleというサービスを経由すればWebベースで投稿もできます。昔記事を書いたので参考になれば*1。
LibreOfficeの多くの開発者は残念ながら日本語を介さないのですが、日本語話者の間で「この障害他の方再現しますか?」「どなたか情報お持ちですか?」といった情報を交換することができます。場合によっては、後述のBugzillaに障害を報告するのに手伝ってくれる人がいるかもしれません*2。
AskBot
LibreOfficeについての質問とそれに対する回答を日本語で行えます(/ja
を /en
にすれば英語サイトにもアクセスできます)。StackOverflaw的なといえばピンとくる人もいるかもしれません。今だとLibreOfficeのメニュー「ヘルプ > オンラインで助言を求める」からたどり着けるので、意識せずに利用されている方もいらっしゃるでしょうか。
このサイト自体は不具合報告の場所ではないのですが、「この動き不具合?それとも仕様?」みたいな質問をすることはできます。残念ながらいまだと質問する人も、なにより回答者が足りてない感があるので、皆さんどしどし使ってくださいませ。こういうことなら自分回答できるよ! という人は超ウェルカムです。
日本語(に限らずCJK)の不具合について相談する英語の場所
ということで以下は英語になります。
Bugzilla
相談というか不具合報告の場所ですね。ただ、もちろん不具合チケットの上で議論することもありますけども。
TDFのBugzillaには「バグを集積するバグ票」である「メタバグ」というものがあって、CJK周りは次の二つのメタバグをウォッチしておくのがいいです。「このバグすでに報告されてるのかなあ」という場合もこれを見るといいですね。
- 113195 – (CJK-Japanese) [META] Japanese language-specific CJK issues 日本語について
- 83066 – (CJK) [META] CJK (Chinese, Japanese, Korean, and Vietnamese) language issues CJKについて
- 106045 – (Vertical-Text) [META] Vertical text direction issues 縦書き
他にも、以下のメタバグも関係あるかも*3。
- 103729 – (HarfBuzz-regressions) [META] HarfBuzz-based common text layout regressions 5.3から採用された「新レイアウトエンジン」に関するもの
- 71732 – (Font-Rendering) [META] Bugs related to text rendering, typography and font features in LO テキストの割付や描画についてのもの
「俺の報告したバグ票をメタバグに紐付けるにはどうしたらいいの?」というのはメーリングリストなどで聞いてくださいませ。基本的にはバグ票のDepends OnにメタバグのバグID(例えば日本語メタバグなら113195)を指定すればいいだけのはず。
Telegram
初日のエントリでも紹介しましたが。
先程のメタバグに報告するのが重いなーという方はこちらでまず相談するのがいいかもしれません。ここにはLibreOffice WriterのCJKバグをもりもり直してくださっている台湾のMark Hung氏が常駐してるので、Writerのバグについては特におすすめ。
開発参考資料
俺はLibreOfficeのCJKのバグを直したい! っていう人に開発参考情報をご提示したいのでございますが、私かなり昔にトライして挫折したので……。
ちょっとURLを見ると悲しくなるのですが、レンダリング系についてはこちらがとっかかりかなあ。
Writer/Text Formatting - Apache OpenOffice Wiki
前述Mark Hung氏に(月曜日夜10時の台北市内のモスバーガーで一緒に晩御飯を食べながら聞いたところ)、これも昔のブログ記事からの引き写しになりますが、
とのことなんで、みんな頑張りましょう。
個人的には、少なくとも関東と関西、さらに台湾とオンラインでつないで開発HackFestをやりたいなあって思ったりしているので、やるなら俺も参加したい! という方、個人的にお声がけくださいませ。
明日のカレンダーはまだ空席なんですよね。誰か手を上げてほしいです><