iOSDC 2018に参加と登壇してきます。
表題にある通り、iOSDC 2018に参加します。前夜祭から参加、9/1には登壇します。 iosdc.jp
I will blogを開催前からですが、ブログ書いてたらプレゼントもらえるらしくこういうのに弱いのでブログ書きます。
資料作る前にブログ書いてる。そろそろ尻に火がつく状態。
今年は事前にブログを書いて下さった方に当日ちょっとしたプレゼントをする予定です。参加者のみなさまも是非!! #iosdc
— iOSDC (@iosdcjp) July 27, 2018
書くこと
参加者のみなさまは「自己紹介」「iOSDCに行くよ!」「参加予定の日」「気になってるトーク」「Twitterアカウント」なんかを書いておくと、現地でのコミュニケーションに良いかも!そして昨年参加の方、何か知見があればシェアーしてください。初参加の方の参考になると思います。 #iosdc
— iOSDC (@iosdcjp) July 27, 2018
自己紹介
京都で働いてます。エンジニアですが、最近はマネージメントばかりです。そんな中で技術ネタでCfP通ったのでちゃんと技術者としてお話しするつもりです!
自己紹介プレゼン
去年は「英会話サービスのために作成したビデオチャットアプリの技術」という内容で登壇しました。
今年は「WebSocketをiOSに持ち込んで辛い思いをした経験がありますか!?」という内容で登壇します。
iOSDCのどこにいるか / 参加予定
9/1(土)の16:00からTrackCで喋ります。全日参加予定ですが、関西から参加するので基本ぼっちだと思います。関西弁聞きたい方肩叩いてください。きっとボケます。
https://fortee.jp/iosdc-japan-2018/proposal/1e7fe56b-79da-454f-8a2f-08b1a8943aab
気になってるトーク
※まだチェックできてない。
Twitterアカウント
taminif (@sbntaminif) | Twitter
去年から得た知見
おそらく今年もTrackごとに部屋の大きさが違うのですが、去年のクロージングで実行委員長が
「TrackB/C/Dのセッション(部屋の小さいセッション)でも、話を聞きにきてくれた方にベストトーク賞の投稿を呼びかければ賞に入れる数だった」
とおっしゃられていたので(言質は取れていない)今年は実践して呼びかけてみようと思います。
ぜひ聞きにきてベストトーク賞入れてください。検証結果出します。
その他
チャレンジングな夏にしたい。最高の夏にしような
8月は色々とチャレンジする月にしたい。
— taminif (@sbntaminif) August 4, 2018
関西Node学園3時限目で登壇しました
概要
表題の通り、関西Node学園3時限目に登壇して来ました。今回はLINE株式会社さんの京都オフィスをお借りして開催させていただきました。
今回私は「LINEで馬券を購入する」というタイトルで登壇してきました。
続きを読む発表資料です!存分に喋りました!!!ご静聴ありがとうございました!#kng3 https://t.co/oBp7L3bvyp
— taminif (@sbntaminif) August 3, 2018
良い勉強会に参加するとブログを書きたくなる
PHPカンファレンス関西2018に参加しました。用事があったので途中で抜けたんですけど、良い話が聞けて参加して良かったと思いました。PHPの垣根を超えた幅広い話や、ブースの盛り上がりはとても良いと思いました。関西で大きなカンファレンスやることがとても少ないので、開催される際は積極的に参加したいと考えています。
この前後で関西Node学園2時限目を開催し、関西Node学園3時限目を予定しています。3時限目はこれからですが、2時限目がすごく良かった話をまだブログに書いていなかったので書きます。
関西Node学園2時限目すごく良かった
今回、初めてfreeeさんにスポンサーしてもらって、飲み物と食べ物を用意してエンジニア同士の懇親会の時間を設けることができました。自分は結構準備や当日の設置に時間を取られたんですけど、大雨の中来ていただいて楽しんでもらえてるように見えたのでとても良かったと思いました。
関西のエンジニアの交流がひとつできた気がして、関西のエンジニア界隈を盛り上げたいという動機から始めたので、進捗ありましたって感じになりました。 これもスポンサーしてくれたfreeeさんや会場使わせてくれたさくらインターネットさんのおかげだと思うし、今後もっと多くの技術者さんや企業さんを巻き込んで関西で勉強会を盛り上げていきたいと考えています。自画自賛許してください。
関西Node学園3時限目やります。
宣伝になるんですけど、間髪入れずに3時限目やります。大阪だけでなく京都でもNodeエンジニアを盛り上げていきたいです。 2時限目に負けず良い勉強会だったと思えるような勉強会にするよう心がけますのでぜひ来ていただきたいです。
良い勉強会に参加した後はブログを書きたい
これに対してなぜかはわからないですし、なぜかを議論するつもりは特になかったりします。良い勉強会に参加した時は帰った後も興奮が収まらずブログに書きなぐってすぐに公開したい気持ちになります。
すぐに書かないと忘れるからかもしれません。他の人に良い勉強会を共有して、教えてあげたいのかもしれません。
でも、ブログ書くことはすごく良いことだと思います。
1時間頑張ってブログを書けば、ブログを書くことで他の参加者や主催者に感想やKPTを教えることができたり、ブログを読んだ人が次回参加してくれたり、自身の勉強会参加した知見をまとめたりできると思います。
最初のきっかけはiOSDC
2017年のiOSDCがすごく良くて、その時はとにかくブログに書きたいという気持ちになりました。よく考えたらこのブログの開設理由がiOSDCのブログを書きたいからで、私のブログ意欲は勉強会駆動なのかもしれません。
iOSDCはすごく良いです。楽しいし勉強になるしエンジニアたくさん集まるしで私がもっとも参加した方が良いと言えるカンファレンスです。今年も開催されるのでぜひ参加しましょう。私も登壇する予定です!
つまり
みなさんも勉強会に参加した後はブログ書いて盛り上がった勉強会をさらに盛り上げましょう。
今日言いたいことはそれくらいです。
puppeteerのHeadless modeの意味
TL;DR
puppeteer.launch
のオプションの headless
をtrueにするとChroniumのUIが立ち上がり、目視で動作が確認できる
はじめに
puppeteer.launch
でbrowserオブジェクトを生成する時にオプションで headless
を指定するとどうなるのか
何が起こるか
headless
をtrueに設定するとスクリプトを実行した時にUIありでChroniumを実行します。Chrome59でヘッドレスモードが搭載されたのでUIなしにChroniumを動かすことができますが、UIありでも実行することが可能ということです。
これを使用することで、自分の書いたスクリプトがどう動くのか目視で確認することができます。指定した通りにボタンが押されるかや、読み込み完了がどのタイミングなのかを見て確認することができます。
実行パスに注意
同じ puppeteer.launch
のオプションの executablePath
でChroniumもしくはChromeのパスを指定することができる。Macの場合、Chromeをインストールしていればここに何も指定していなければ普段使うChromeが起動してUIが見れる。
まとめ
実運用する際に設定する機会は少ないですが、実装中に確認しながら作ることは多いと思うので初期は設定して開発することをお勧めします。
Headless Chromeとpuppeteerを使って馬券購入APIを実装する
99%の人には言ったことはないのですが、実は競馬を毎週見るくらいのファンです。
やりたいこと
Headless Chromiumとpuppeteerを使って馬券購入の手順を自動化、入力値を渡すことで
その馬券を購入。WEBで完結するようにしてAPI化する。
前提として
JRAのサイトなんですが、公式サイトやインターネット購入サイト、購入履歴を見れるサイトなどいくつかあるのですが
もれなく現代のWebから取り残されたような作りになっています。
おそらくスクレイピング対策としてこのような作りにしているのではないかと邪推しているのですが、真意はわかりません。
例えば、以下のサイトから「出馬表」 -> 「開催のボタン」 -> 「レース指定」と進んでみてください。全てPOSTで遷移、URLにパラメータは一切残さない仕様です。
それでもこの速度を出せるのはおそらくサーバーを札束で殴っているからではないかと思います。
http://www.jra.go.jp/
業務に感情を持ち込む
よく「業務に感情を持ち込むな」って言うと思うんですけど、最近業務にもどんどん感情持ち込んだ方が良いと思ったので、なぜそう思ったか書く。
ただし負の感情、テメーはダメだ。
なぜそう思ったか
今の会社で仕事している中で、全く感情を入れないような完全に論理的だけで仕事される方が何人かおられるんですけど
その人と一緒に仕事していると周りの人が結構しんどそうにしているのをみて、入れないことって本当に良いことかわからなくなりました。
そしていやむしろ入れた方が良い仕事できるんじゃね?笑ってる方が良いじゃん。むしろ積極的に入れていくべき。と言う考え方に変わってきました。
仕事しているのは人
やっぱり人間なので、全く感情もなしに良い仕事することってできないと思うんですよ。
ただコード書くだけでも、淡々とコード書くよりも気分乗せて書いた方が進みは良いと思うし、音楽とか聞いて集中しやすくするのも感情入れてるのだと思います。
疲れているときに良い考えが浮かばないのも、気分が落ち込んでいるときに良い仕事できないのも感情が入っていることで問題になるのかもしれないですが、
このときに感情を排除して仕事するよりちゃんと休んでから仕事に戻る方が良い判断だと思います。
人と仕事している
一人で仕事しているならともかく隣や周りに人がいるわけで、無表情で話すより笑いながら話した方が相手も身構えないしリラックスできるんじゃないかと思います。
好意で仕事を決めるのはダメですが、チームでも雰囲気とかあるわけで
良い雰囲気を作るためにも良い感情を積極的に入れていった方が良いと思います。
感情を入れてはいけないタイミング
判断する時
仕事中にはどんどん感情を入れていくべきだと思うのですが、何か物事を判断するときは良い感情でも悪い感情でも入れてはいけないです。
ここは完全に計測した数字や説明できる内容で決めるべきです。
判断に感情を入れてしまうと、よくないものに対して「この人の意見が良いと思うから」「いや頑張ってたから」という理由だけで決めてしまって
誰も得しない結果になってしまうのが見えています。
負の感情を持っているとき
そもそも負の感情は絶対に入れてはダメで、チームの雰囲気悪くするわ心身ともに疲れるわで良いことは全くないです。
強いて言えば、やってはいけないことをやっている人に対して、怒りの感情を少しだけ込めるか無感情で怒るかだと前者の方が良いかなと思うくらいです。
また、自分が負の感情を持っているときに無理やりポジティブに感情入れて仕事しようとするのも良くないです。そういう時はちゃんと休む。
あと、これは自然なのか機嫌悪いのか判断つかないんですけど、舌打ちと貧乏ゆすりする人はマジでやめてほしい。
やっている人には誰も近づかなくなるし雰囲気悪くなるしで良いことない。
「気持ちを整えるためです」なんていうならそのやり方を変えた方が良い。
まとめ
どんどん感情入れてやっていこう。
そして良い感情を入れて良い成果をあげましょう。
"なぜなぜ分析"は炎上が落ち着いてから実施しよう
炎上してる時って、何もかもうまく進まないですよね。そもそも炎上させるなって話なんですけど
まあやってしまったものはしょうがない訳で、炎上した時はまず炎上を収めるために愚直に動くのが一番良いと思っています。
その時にやってしまった失敗に対して、その失敗は次回同じ失敗をしないように原因を洗い出す必要はもちろんあるんですけど
その原因を洗い出す時にやるなぜなぜ分析を炎上中にやるのはやめておこうという話です。
炎上中になぜなぜ分析してはいけない理由
余裕がない
炎上中は余裕がありません。次から次へとタスクが降ってくる状態です。
そんな状態でなぜなぜ分析をやっても、正しい分析はできません。当事者はその時間を次の作業にあてたいと考えます。
ただでさえ毎日遅いのに、これでさらに遅くなることで良い思いする人はいません。
同じ作業をする時も、なぜなぜ分析するより失敗を繰り返さないようにするだけが精一杯だと思います。
受け入れられない
炎上中は余裕がありません。気持ち的にも辛い時期です。
その状態で失敗したとなると、さらに余裕は無くなります。
だいたい泣きそうになってます(主観)
その状態でのなぜなぜ分析はたとえ感情が入っていなくても、責められるように感じてしまいます。
結局落ち着いていない状態でやることになっちゃうので、上手に洗い出しはできない、
なぜなぜ分析の結果を受け入れることも難しいです。
炎上が落ち着いたら分析をしよう
炎上が落ち着いて、チームが上手く回るようになったタイミングで
なぜなぜ分析をしましょう。
その分析は必ず次回に活かせるし、それが成長することになります。
なので、なぜなぜ分析をしないのもNGです。せっかくやらかした失敗なんだから活かさないともったいない。
ちなみに、なぜなぜ分析をする際に感情を持ち込むのはどうなのかという話がありますが、
私は怒り以外の感情は持ち込んだ方が良いと思っています。
その失敗が個人のミスだったのか、キャパオーバーだったのか、防げない事故だったのかで
当人の受け入れ方も変わりますし、防げない事故で怒られても理不尽なだけです。
全く感情を入れずになぜなぜ分析をすると逆に怖いという印象を与えてしまう可能性があるので、
それはそれで受け入れられなくなると思います。
まとめ
分析は絶対に必要ですが、やるタイミングは見極めましょう。