技術書典用 被サークルチェック数チェッカー

毎晩、被チェック数が増えているかな?とページをアクセスして覗いていましたが、自動化の話を見かけたので自分もチャレンジしました。前記事の続きとなりますが、ようやく動く物ができたので共有します。自分は今これをつかって確認しています。

被サークルチェック数チェッカー

Selenium とヘッドレス Chrome で技術書典の被サークルチェック数を取り出すものを書いてみました。

最初は操作を確認しつつ、うまくいってからヘッドレス化してという作業手順でやっていました。このとき、ヘッドレス化してエラーが出た場合には進行状況を見るのにヘッドレス Chrome の画面を撮影してデバッグしていました。
基本的には、Google cloud function で動くチェックツールを公開されている方のコードを参考にして各テキストやボタンの操作をしていきました。

自分の場合には Microsoft Teams を普段のチャットツールとして使っていることもあり、チェック数をメール経由でチャットの方に通知するようにしています。
必要なものはメールサーバーがありますが、これは各自のメールサーバーを使えばいいと思います。 SMTP の STARTTLS 方式にもこのスクリプトは対応できています。

基本的には、ここまでと書かれた内容で各自の状況に合わせて変更してもらえればよいかなと思います。

定期ループ化

結局、自分のローカルPCでタスクスケジューラに登録して定期タスク化しています。
なのでしばらくは電源を入れっぱなしで処理を回していきます。どこかのクラウドVMで動かすにはちょっと勿体ないですし、そこら辺に転がっているラズパイで cron 設定するというのもひとつの手ですね。

おまけ

Google のスプレッドシートも使ってそちらにも記録していくと、被チェック数の推移を知ることができて面白いかと思います。
手元のスクリプトではこの改造もやりつつなのですが、gist に公開するまでは至っておらず。そのうち整えて次回の書典には公開できるようにしておきたいところですね。

最初は GAS (Google Apps Script) で全て処理できるんじゃないかと思っていたのですが無理でした。
GAS で技術書典のページにログインして、被チェック数を得ることが出来た人、是非教えて下さい。

参考

今回のことでいくつかのサイトの情報を参考にして実装しました。

まとめ

今回初めてこういったツールを準備してみました。Selenium を使って、操作するのも実は初めてなので、このスクリプトにまずい点があるかもしれませんし、もっといい方法があるかもしれません。こうするとよいよ、とアドバイスがもらえたら嬉しく思います。

それはそれとして、新しいものにチャレンジするって大変ですがワクワクしますね。


Selenium で Headless Chrome インストールに失敗した話

技術書典7向けの作業をしていて、ここしばらく追われてました。CEDEC 2019 とかでは、もう DirectX Raytracing を使っての話が多く、そろそろ本ブログでもやっていかないとなぁと思っている次第です。

さて技術書典のサイトで被チェック数が確認できるのですが、これを確認するのを自動化してみようと試行錯誤していました。既に、 GCP の Google cloud function で動くチェックツールを公開されている方が居まして、これを使えばそれで終わりです。
しかし、自分はGCPのほうは全く無知なので Azure や AWS で出来ないかなぁと思ってトライしていました。結果としては、これらの FaaS ではヘッドレスChrome が動作できないのと、元々のページが動的であることの2点より完全敗北しました。

最初の FaaS でなんとかやりたい!という野望は砕け散ったので、素直に Selenium と Chrome でなんとかすることにしました。Seleniumでヘッドレス Chrome を pip で次のようにインストールしたのですが、バージョン違いを言われて苦戦しました。

どうやら既に Chrome がインストールされている状況で、それと pip でインストールした Chrome のバージョン違いが起こると起動出来ないようです。自分の環境では次のようなエラーメッセージでした。

そこで既にインストールされている Chrome のバージョンを調べて、 chromedriver-binary のリポジトリ(サイト)を確認して、近いバージョンのものを選んでインストールすることにしました。コマンド例は次の通りです。

とりあえずはこれで Selenium から Chrome を起動して操作可能になったので、操作自動化を頑張ってみたいと思います。


DirectX12 フルスクリーンの罠

DirectX12 でフルスクリーン描画を行おうとしたときに、予想外に色々と苦戦しました。
DirectX12 というよりは、フルスクリーンは DXGI の機能・制御管轄なので、もしかすると今回の話は DirectX11 でも症状が出るのかもしれません。もしかすると環境要因もあるのかもしれませんが、何かの参考になれば幸いです。

出遭ったこと

「ALT+ENTER でフルスクリーンとウィンドウモードを行き来(切り替え)をしたい。」
これを実現するのに苦戦しています。

ディスプレイの解像度に対してのフルスクリーンとウィンドウモードの切り替えは、標準 DXGI の機能で問題なく出来ました。
ですが、描画の内容によっては指定された解像度でフルスクリーンとしたいことがあり、描画ターゲットの解像度を変えるのでは無く、ディスプレイの解像度設定のほうを変更したいという条件になります。

これには初期化時に DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH フラグを設定しますが、これがあると色々と問題に出遭いました。

続きを読む


Vulkan での排他フルスクリーン

Vulkan でフルスクリーンアプリケーションを作ろうと思ったら、全画面のウィンドウを枠なしで作るという方法でした。
いわゆる仮想フルスクリーンの手法です。OpenGL でもフルスクリーンのアプリケーションは同様の手順で作るので、特に違和感はありませんでした。
ただ、DirectX9 時には専用のフルスクリーン設定がありましたし、9.0c 以降では DXGI がそのあたりの設定を引き受けてくれていました。

VK_EXT_full_screen_exclusive

しかしつい最近に Vulkan にも排他フルスクリーンの拡張が用意されました!
それが VK_EXT_full_screen_exclusive です。紹介文を軽く読むと、ディスプレイのコンポジッタを迂回してフルスクリーン化が出来るようなので、画面表示完了までのレイテンシーは短くなるのではないかと期待です。

拡張そのものの説明は https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/VK_EXT_full_screen_exclusive.txt に記載されています。

NVIDIA の環境では、 Windows 版だと 425.89, Linux 版だと 418.52.14 のドライバでサポートされるようです。ただどちらもまだベータドライバなのでその点には注意が必要です。
RADEON の環境では、Adrenalin 2019 19.6.2 から対応されて居るみたいですね。

最近は不安定なドライバを入れて実験する時間がないので、安定版になってから試してみようと思います。


Git LFS について(オブジェクトとロック)

以前に 「Git LFS を使ってみる」という記事を書いたのですが、現在のものと少し合わなくなってきている感じがしたので書き直しました。
Git LFS が出始めの頃と比較すると利用できる環境は格段に増えています。

Git LFS について

出始めの頃は別パッケージとしてインストールが必要でしたが、現在は Git for Windows の中に含まれています。
Git LFS は、指定されたファイルタイプ(拡張子による設定など)によって、特別な処理を行いバージョン管理させる仕組みとなっています。
具体的には、比較的ファイルサイズが大きくなるバイナリファイルを対象に指定して、バイナリファイルへのリンク情報をテキストの形にして git によるバージョン管理に載せる動きとなります。
リポジトリ上では、バイナリファイルは git の標準のデータ構造とは別の場所に格納されていたりします。

現在においては、各種 git リポジトリサービスが、この Git LFS に対応しています。

  • GitHub
  • GitLab
  • GitBucket
  • GitBlit
  • Bitbucket
  • Azure DevOps

ただ Git LFS にもバージョンがあり、現時点においては git-lfs のバージョンは 2.7.2 となっています。この過程で Git LFS の通信プロトコルにも拡張が入ることがあり、機能が増えたり、作業の改善があったりとします。
例えば初期では LFS 対象のバイナリファイルが1つずつしかダウンロード出来ていなかったのが、複数を並列でダウンロード出来るようになったりしました。
こういった点より、リポジトリサービスを提供するアプリケーションもバージョン更新が定期的であることが理想的です。GitBlit はかなりの間、バージョン更新が無いようなので利用はあまりオススメできないかと思います。

続きを読む


OpenGL で描画先独立なブレンディング設定を使う

OpenGL でデュアルソースブレンディングを使うと、出力先カラーバッファが1つになってしまう!という話を聞いて、「1つのカラーバッファに2色出力し、ブレンド設定でさらに演算」という場面ってどのくらいあるのだろうと疑問に思いました。(おそらくデスティネーション色と処理したいのでしょうが)。
そんな中、Multiple Render Target (MRT)で、各カラーバッファのブレンディング設定は独立に出来たはず、と思うことがあったので使い方を確認してみました。
ちなみに、DirectX11 ではカラーバッファのブレンディング設定の独立(個別)は簡単にできます。D3D11_BLEND_DESC構造体を見るとすぐに分かります。

結果としては、 OpenGL でもこのようにブレンディング設定を変えて描画できます。

続きを読む


技術書典6の感想など

技術書典6に本を出す側で無事に参加出来たので、今回もその感想を残しておこうと思います。技術書典への頒布側での参加は2度目となります。
前回は、疲れと解放感から感想まとめまでが時間が掛かっていたのですが、今回は後処理で色々と作業をしていて遅れました。

頒布内容の紹介は別ページを参照ください。

やっぱり物理本はいい

今回も前回同様、物理的な本を出す、ということを重要視していました。但し今回は電子版の用意をしてみることにしました。
物理本の印刷関連は前回体験したので、今回のチャレンジは電子版のダウンロードカードをどうするか、といったところでした。

サークル:すらりんラボが採った方法は以下の2つです。

  • 対面電書でのコード発行
  • BOOTHでのパスワードzipの配布

ここまで準備して挑んだのですが、電子版単体としては売れ行きは今ひとつでした。きっと技術書典という場所も関係しているのでしょう、圧倒的に物理本に人気がありました。
物理本が無くなってから、仕方なく電子版で妥協という方も居たのではないかと思います。

ダウンロードカードですが、安価な価格設定でバリアブル印刷可能なところを見つけるのが大変ですね。
シリアルコードを自分のプリンタでシールラベル印刷して、カードに貼る形式も最悪ケースで考えていましたが、色々と考えると BOOTH でのパスワード zip の配布が一番手軽だと思います。
手軽な方法が採れるということは、コストを抑えられるので物理本のオプションで電子版を付けられる!ということにも繋がります。今回バリアブル印刷でコストを掛けてしまったため、別料金を頂く形になってしまいました。これがさらに問題に繋がったわけですが・・・後ほど。

続きを読む


VisualStudio2019 オフラインインストール準備

Visual Studio 2019 が公開されました!
とりあえずインストールをと思いつつも、今は時間がないのでオフラインインストール出来るように仕掛けてみました。

Visual Studio 2019 のインストーラーファイルを取得した後で、コマンドラインで、 “vs_professional.exe –layout D:\VS2019Ja –lang ja-JP” と打ち込んでファイルを収集させてみました。
この方法は従来通りで変わっておらず、うまく動き出しているようです。


技術書典6に向けて追い込み中です

今週の初めに告知したように、技術書典6へ参加してきます。
DirectX12 や Vulkan の入門書籍を今回は用意しました。
一緒に参加する相棒は3Dオーディオ入門という書籍を書き上げてくれました。

・・・というより、みんな最後の締め間際の追い込み作業中です。

すらりんラボは技術書典6に参加します

なかなかブログ更新出来ていない点がありますが、その分これらの冊子に力を入れたので、是非見てもらえたらと思います。


RDPでGraphicsAPIは実行出来るか実験

前回、RDP で OpenGL アプリを起動させる方法を考えましたが、そもそも他のグラフィックスAPIではどうなのか、気になってきたので調べてみました。

RDP で動作するか?

  • OpenGL : 動作しない
  • DirectX11 : 動作する
  • DirectX12 : 動作する
  • Vulkan : 動作する

まさかの OpenGL だけが動作しないという状況だったようです。確認したのは、2台とも Windows10 1809 の環境で、デスクトップPCとノートPCという構成でした。
低レイヤーグラフィックスAPIのDirectX12/Vulkan らが RDP 経由でも使えたという点で驚きました。画面を単なる画像として送るなら、これらの動作に納得もあるのですが、かつては DirectX9 や OpenGL がリモートデスクトップ環境下で動かなかった時代を味わったために動作しないという思い込みがあったようです。

プログラムコードで考えてみると、デバイスコンテキストが不要な API だと動作しているようですね。あとは、画面ロック・UACの暗転でいわゆるデバイスロストが発生しない時代になってきたから、というのもありそうです。