m_shige1979のささやかな抵抗と欲望の日々

プログラムの勉強をしながら学習したことや経験したことをぼそぼそと書いていきます

なんとなく作ったサイト

http://www.it-check-matome.info/


Github(注意すること)

https://github.com/mshige1979

Perl Beginners #11に参加しました

勉強会情報

場所

東京都中央区勝どき区民館 (東京都中央区勝どき1-5-1)

人数

40人(参加は17人くらい)

日時

2013/11/29 19:00 to 21:00

ハッシュタグ

#perlbeginners

テーマ

スピードアップ

f:id:m_shige1979:20131129185409j:plain

内容

19:05-19:25 基調講演(Perl-Beginnersに参加したら、音速でCPAN Authorになった話)

@magnolia さん

#10で「Blender-Declare」を紹介していただいた方のようですなんか名前が長いとかいろいろあって「Enbld」に改名
スピードアップとしての意味がちょっと違うのかなと思いつつこれも立派なスピードアップかと思いました。
Perl-Beginnersに参加後cpanに登録するアドバイスを受けたり、してcpanに登録して色々あってあっという間に…というお話

19:25-19:40 ビギナーズセッション

スピード・アップではなく初心者としての質問を投げる内容なのでなんでもOK

今回はテストをTDD?化したいけどどのように浸透させるべきかということ

いろいろ議論していたようです。テスト自体は開発を効率化すること自体には反対はないけどいままでがそういう場合は変えていくのはちょっと難しいかと思われる。
リリースの場合に手作業を求められることもそれが理由のような気がする。

seleniumなどもありますけど、対応方法が可変していく場合にそれぞれに対応する学習コストを考えたらテストパターンを書いてその通りにテストするほうが理解りやすいのかも…
コードから確実にテストコードが自動生成するかテスト方法がある程度簡略化できないと難しいですね。

私自身はまだ、会社の古い体制に合わせていますが、そのうち技術面で破綻していくので新しくやりやすい方法を調査しながら変えていけばいいのかと思っている。

テストコードの場合は書いてテスト、新しい仕様→書いてテストになるのでなんか面倒な感じになりそう。
ライブラリでテストする箇所が制限されればイケるかも…なんかこればっかりはいろいろやらんとわからない。私自身テスト嫌いなのであまりいい方法が思いつかないな…

ライトニングトーク

19:50-20:50

スピードアップの前に分析必要よね。

@i47_rozary さん

スピードアップの前に分析を行ってボトルネックを調査しましょうというお話

スピードアップ・チューニング

@ytnobody さん

多分、私が一番聞きたかった内容
Benchmarkというモジュールを使用してベンチマークを測って対応すること
if文を少なくしたり、ループ回数を減らすことでスピードアップできることがわかりました。

問題としてはsqlなどを使用する場合、SQLを一括で処理することにしてもループがどこかにある場合はそれが原因で逆に遅くなるかもしれないということ

プロセスの永続化でコスト削減

@xtetsuji さん

プロセスをベースにしたスピードアップのベースの話
ただ、nginxやstarmanなどはほとんどわかっていないけどプロセスが溜まってしまってしまう問題などがあっていろいろと障害の元になりそうなことはわかりました。

所感

いまは環境回りの調査ばかりしているのでPerlの勉強はしていない…
class、DB制御、ベンチマーク、テストなどまだやらないといけないことが多くあります。

少しづつコードを書いておかないといけないな~簡易プロジェクトとしていろいろ作っておきたいけどデータベースなどをベースにしたり
テストなどはまだ、時間がかかりそう。

とりあえず、近いうちにベンチマークのコードで速度調査方法を理解しておこう



体調管理

気温の変化で風邪気味でしたけどなんとかなった(なってなかったような。
まあ、風邪には気を付けよう

広告を非表示にする