ソモサン

私rohkiによる活動や読書の記録をつらつらと書くページです

YAPC::Kansai 2017 OSAKA で会場のあれこれしてた #yapcjapan

yapcjapan.org

というわけで、↑のあれこれやってました。
すべては下に集約されるわけですが。

会場に関してやっていたことを以下つらつらと。

続きを読む

Rust で素朴に HTTP リクエストを投げる

以前、Windows でHTTP リクエストするために、1時間ほど格闘した rohki です。
ツラカッタ…

で、格闘する原因となった HTTP ライブラリ hyper の OpenSSL への依存が v0.10 でなくなったとのこと。
Release v0.10.0 · hyperium/hyper
Remove SSL feature (and openssl/security-framework dependencies) · Issue #985 · hyperium/hyper

じゃあ https どうすんの、ということですが、Client は reqwest で ok でした。*1
実際書いてみるとこんな感じ。

extern crate reqwest;

use std::io::Read;

fn main() {
    let mut resp = reqwest::get("https://www.rust-lang.org").unwrap();

    let mut s = String::new();
    resp.read_to_string(&mut s);
    println!("{:?}", s);
}

素朴!!
ライブラリがどうのとか、環境変数とか何もなしですぐ使えました。
ありがたやありがたや。

*1:内部で hyper と native-tls を使っている模様

大阪から日帰り弾丸で builderscon に参加した

大まかな感想

面白かったー! なんだろう、異種格闘技戦というかごった煮というか闇鍋というか。

buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。

公式サイトや Opening で言われていた通り、祭りって言葉がぴったりでした。
あと Geek! なぜそうするのか、なんて質問はきっと野暮ってぐらいにつきぬけてる感がありました!

来年も是非是非参加したい!

以下詳細

5時起床…!

いやぁ、エンジニアは朝に弱いというのに 11月ぐらいにホテルを取ろうとしたら、渋谷と品川周りが埋まってて無理だなー、ということで当日行って帰ればいいという脳筋スタイルと相成りました。
挙句登壇者の方を除けば一番のりという。僕は何をしているんだw

OSSWindows で動いてこそ楽しい (mattn さん)

今回の僕の主目的! や、もう言い切ります!
本人もお話しされてましたが、すごい貴重な気配を感じる…!
僕自身 Windows の開発をしているので、お話しいただく内容に終始うなづきっぱなしでした。
動かないのを動かすから楽しいってのは、すっごくよくわかるんですよね。
できないって言われると燃えるっていうのか。

調子に乗って以前詰まった開発について、質問したりもしました。
で、Go 1.8 のWindows のシステムの証明書ストアへのアクセスを、僕が作ったってでてくる mattn さん。やはりすごい。

php.iniについて知る (uzulla さん)

闇しか感じない…

ini ファイルを複数舐めるのに、重複する設定が上書きとか、辛い!!
おまけにあるディレクトリにいたっては、その中にある ini ファイルを全部なめたりするし。
これも質問させてもらって、ディレクトリの捜査順序ってどうなりますか? と聞いたところ、呪文が帰ってきました。 やはり辛い…

そろそろプログラマーFPGAを触ってみよう! (kazunori279 さん)

聞きながら、だいぶ思考を変える必要があるなーと感じました。
それを踏まえて、HLS をやる場合それを前提としたコーディングをして性能最適をすべきか、っていう質問をしようと思っていたんですが、忘れてしましましたw

で、帰宅

レッドブル 2 本とフリスク、さらに帰りがけにホットコーヒーと完全に目が醒めてますw
まぁ 5 本飲んだ方もいたようですし、きっと大丈夫。

来年は話す側で参加するために、ネタを仕込んでいきたいと思います。
きっと Windows 開発は競合が少ないはず。きっと…

Rust でネストが深くなったけど未解決

前に行った into_iter() は無事動きました。何だったんだ。

今はこんな感じです。

perf_client/pdh_wrapper.rs at master · ROki1988/perf_client · GitHub

impl PdhController {
    pub fn new(path: Vec<PdhCounterPathElement>) -> Option<PdhController> {
        pdh_open_query()
            .map(|q| {
                let cs = path.into_iter()
                    .filter_map(|e| {
                        pdh_make_counter_path(&e)
                            .and_then(|p| pdh_add_counter(q, p.as_str()))
                            .map(|c| {
                                PdhCollectionItem {
                                    element: e,
                                    hcounter: c,
                                }
                            })
                            .ok()
                    })
                    .collect::<Vec<_>>();
                PdhController {
                    hquery: q,
                    hcounters: cs,
                }
            })
            .ok()
    }
}

ふかい! ふかいんだよ…
依存があるのはそうだからしかたないけど、どうにかしたい。
do 記法とか for 内包表記とかにあたるものがあれば、まだましになるはず?
相変わらず PdhController 返してるあたりが胡散臭いけど、またあと。

Rust で Windows のパフォーマンスカウンターをとってみる

前回作った車輪の再発明!! 言い訳はしない!

GitHub - ROki1988/perf_client

色々頑張った結果…

fn main() {
    let path_list = vec!["\\Memory\\Available Mbytes"];

    if let Some(pdhc) = PdhController::new(path_list) {

        let m = pdhc.current_values();

        println!("{:?}", m);
    }
}

main 関数がこうなりました。だーいぶ隠せたかな?

大まかな流れ

とりたいメトリクスの PATH 配列を入力として、カウンター取得のための構造体を作成。
current_values() を呼び出すたびにそのタイミングでの値が Vec で返ってくる寸法。
PDH_HQUERY の開放も、 PdhController がスコープ外になって消えるタイミングでやるように trait を実装。

改善すべき点

  • 一番最初の HCOUNTER 取得から PdhController 生成の部分が胡散臭い。
  • PATH の部分を文字列でなく PDH_COUNTER_PATH_ELEMENTS の wrapper なりにすれば、もうちょい使いやすくなるかも。
  • 値を返すのでなく、値を順繰りとれる iter は実装中。

iter ができたら、送信部分つくってみるかー

OOP の勉強がてら Windows の Graphite クライアント書いた

動機

Windows のパフォーマンス計測をしたかったのです。
で、クライアントの計測なので、ランタイムインストールはよけたい所でもあったのです。
インストールする物が多かったり大きかったりすると、協力して貰いにくく…

C# 製の↓のがあったんで展開してみたわけです。
CryptonZylog/carbonator: Windows service that collects performance counters and reports metrics to a Graphite server

結果、CPU 使用率が 5% とかで、思った以上にくってたんですよ。

OOP とか色々勉強したけど、素振りばっかだなーってこともあったので、書きました。

ROki1988/PerfSrv

お仕事の環境と同じ、Delphi で書きました。
Rust で書こうとも思ったんですが、まず WindowsAPI 定義からだったので、とりあえず後回し。

何かちょうど良い感じのブログ があったので、ここで計測していた23個のメトリクスで負荷計測。
取得周期は 1 秒毎。

結果

  • CPU 使用率: 0.05%
  • メモリ使用量(ワーキングセット): 15MB
  • ディスク IO: 0
  • ネットワークIO: 1KB/s

f:id:rohki:20160907005205p:plain

ディスクは書いてないですからね。そらそうだ。
結構かるい? と思ってます。
この辺は Rust や Golang の勉強を兼ねて作ってみて、比較できるようにしたいです。
需要が何処にあるかは定かでないですが。

動作確認等々

ローカルの動作確認では、下のアプリを使用しました。
Packet Sender - The Free UDP and TCP Network Test Utility

で、本番との接続は下のサービスを使用しました。

環境もっかい構築とか苦行ですし。

ただ…

社内で動かないという・・・
どーもネットワーク関係っぽいんですが、特定には至らず。
Hosted Graphite に繋がってよっしゃーとおもったらこのざまですよ。

(追記)Graphite の UDP 受信がデフォルト OFF のままだっただけでした orz

上は特定して直すとして、さらに色々粗々なので、直します。名前とか、設定ファイルとか。
OOP 的にもっと整理できそうですし、テストコードとかもちゃんと書かないとです。

OOP の話

は、土曜日にとっときます。話すネタがなくなる!!

rad-studio-osaka.connpass.com

Rust + Windows でウィンドウタイトルとかとってみる

なにしてんねん

社会人生活4年目で、Windows に染まりきってしまいました・・・
ShellScript で GCC ビルドをしていたあの頃にはもう・・・

さて

Rust をこのごろ触ってます。
で、Windows でも API がちょろっとあったので、試しにやってみました。

ROki1988/active_window_logger

で、僕的に おー と思ったのが、この部分

    let mut title = vec![ 0u16; (length + 1) as usize ];
    unsafe {
        user32::GetWindowTextW(whdl, title.as_mut_ptr(), length + 1);
    }

unsafe 何ていうから malloc/free なのかなーなんて思ってたんですが、するっと確保出来ました。
言われてみれば、たしかになー。頭固かった。
mut vec!as_mut_ptr() を返せば、変更可能なメモリ領域ですよ。
僕みたいな API べたべた触る人間にはありがたい限りです。

つぎー

構造体がサンプルの哲学者ぐらいでしか書いてないので、そろそろちゃんと書きます。
trait とかもまだ。
構造体配列をとってきてとかも面白そうですね。

Lifetime? HAHAHA!

参考 URL