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です。せっかくやらかした失敗なんだから活かさないともったいない。

ちなみに、なぜなぜ分析をする際に感情を持ち込むのはどうなのかという話がありますが、
私は怒り以外の感情は持ち込んだ方が良いと思っています。
その失敗が個人のミスだったのか、キャパオーバーだったのか、防げない事故だったのかで
当人の受け入れ方も変わりますし、防げない事故で怒られても理不尽なだけです。
全く感情を入れずになぜなぜ分析をすると逆に怖いという印象を与えてしまう可能性があるので、
それはそれで受け入れられなくなると思います。

まとめ

分析は絶対に必要ですが、やるタイミングは見極めましょう。

関西Node学園を立ち上げました。

4月20日にさくらインターネットさんのイベントスペースをお借りし、関西Node学園を開催しました。 開催に至った経緯と、立ち上げについて書きました。

Nodeの勉強会を関西でやりたい

当方関西住まいであることから、ずっと関西の勉強会を充実させたいと考えていました。
その中でも、普段から業務で使用しているNodeの勉強会を社内でやりたいという話は何度かやっていて、どこかで機会があればと思っていました。
特に知見共有をする機会がないので、一口にNodeといっても

• ECMAやらTypeやらFlowなど何で書くか
• ReactやらVueやらAngularなど何を使うか

などなど話を聞きたくなるようなことが多くあると思っていて、交流する場が欲しいと思っていました。

東京とその他の格差

以前より、勉強会はまだまだ東京一極集中で、それ自体は人が多いから仕方ないとは思っていて
でもやっぱり関西でも同じように勉強会をやって格差を減らしたいと思っています。
一言で言うと「関西のエンジニア業界を盛り上げたい」です。

企画開始するまで

2月にfreeeの方にお会いした時にNodeの勉強会をやりたいんですよね〜と軽い感じで話をしたら、関西にいるNode学園祭の実行委員の方を紹介できるとのことだったので
勢いで紹介してもらい、言い出したからには一回は必ず実現させたいと息込んで、同僚も巻き込んで開催することを決めました。

Nodeの勉強会なら知名度や参加率上げるためにもNode学園を冠したいと思ったので、古川さんにも確認を取っていただいてスタートしました。ほぼ勢いだけで二ヶ月動いて開催まで色々とやってました。

準備

会場は無料で貸していただけるところでさくらインターネットさんに連絡して、新しく始めるなら学園だし4月が良いということで空いているところを抑えていただきました。
同時に、登壇者が全く集まらなかったら企画倒れになりますので事前に登壇できる方を探してお願いして、connpassページを作成して登壇者も合わせて募集開始しました。

あとは、当日の受付や会場設営をどうするかなど考えることはありましたが基本的に宣伝するだけで、
connpassで登壇希望が集まらなかったら改めて声かけして集める想定でしたが、幸いにも登壇したいと声をあげていただけたので
あまり動くことなく開催できそうな感じになりました。

どうだったか

無断キャンセルはあったものの、40人以上ご参加いただいて
登壇者もみんな盛り上げてくれたので、個人主観ですが大盛況で終われたと思います。
登壇者で声かけした方の中には東京から参加していただいた方もいらっしゃって、本当に感謝したいです。
時間がおして予定通りに終われなかったり、東京から参加いただいて満足にお礼を言えなかったのは運営が未熟でドタバタだったからです。ごめんなさい。。
せめて懇親会は予定しておくべきでした。

ただこれなら、次回以降もやっていけそうだと思ったのですでに企画を進めています。尻すぼみにならないよう定期的にやっていって、
Node学園は関西でも参加できるんだぞって認知されたいです！

まとめ

漠然とやりたいなーと考えていても、やっぱりきっかけは大事で
実際きっかけができるまで動くことはなかったですが、動き始めるとすぐで
そのきっかけがあれば深く考えるよりもまず行動するのが一番良いと思います。
許可を求めるな謝罪せよってやつですね。迷惑かかるようなことはダメだと思いますがそこをちゃんとケアすればどんどんやっちゃうべき。
ただし絶対に一人ではできないと思います。特に登壇者探すときは自分一人のネットワークだと限界があるし、当日も一人では回らないので一緒にやってくれる人は絶対必要です。

あとこれは会場でも話させていただいたんですけど、関西Node学園とした件について
これから関西いろんなところでNode学園やっていきたいと思います。私も京都で仕事していることもあって
大阪にしてしまうと毎回大阪になるのも辛いし、京都でもNode学園やりたいと思っているので
ぜひ（無料で）会場お貸しいただけるところを切望しております！

言いたいことはそれくらいです。関西だってやれるんだ目指すは東京レベルの盛り上がりだということで
改めてみなさんお疲れ様でした！次回もよろしくお願いいたします！知見共有しましょう！登壇してね！！

マネジメントを言語化する

最近、お仕事の比率でマネジメントすることが増えてきた。自分はマネジメントについて人より優れているとは思っていないけど、見ていてこれはもうまずいと思うところで口出ししてきた結果フォローに入ることになるケースが多い。
そこで、マネジメントできてない人はどうしているのか、できる人とできない人の違いはなんなのか、自分はどうしているかを考えることが比例して増えてきて、これはブログに書けるんじゃないかと思うので書いてみる。
ちなみに先日あった情報処理技術者試験のプロジェクトマネージャとは特に関係なかったりする。たまたまタイミング被っただけです。

マネジメントとは

ejje.weblio.jp

経営，管理，支配

マネジメントは特殊な能力か

例えば、マネジメントはプロスポーツ選手のような一部の人にしか仕事にすることができない作業なのだろうかというと、そういうものではない。資格は必要なく、やろうとすることは誰にでもできる。
ただしマネジメントスキルは存在し、このスキルは身に付けることができると思う。
つまり、マネジメントスキルは特殊ではないが、ちゃんと身に付ける必要があると言える。

間違ったマネジメント

この時、マネジメントスキルをつけていない人がマネジメントポジションにつくとどうなるか、容易に想像がつくと思う。
だいたい失敗する。もしくはデスマーチ化する。
こういう人でも上手く行く場合はだいたいチームメンバーに優秀な人がいる。つまりそのマネージャーの功績ではない。
以下は、プロジェクト進行時に私がよく見るマネジメントスキルをつけていないと思う例である。

カレンダー見るだけの人

プロジェクトを進めている中で、各メンバーのタスクを確認し、そのタスクがスケジュール通りに進んでいるか確認するだけのマネージャー。
これがなぜ間違いかというと、時間を管理することはできないからである。
つまり、マネージャーがスケジュールを見たところで、現状を何も変えられないのである。
仮にスケジュールに遅れが出た場合にマネージャーのやることは、遅れた原因を調査し、その問題を取り除くことである。
ただスケジュールを延ばすだけでは、また同じように遅れるだけである。

依頼と丸投げを間違えている人

プロジェクトメンバーにタスクをお願いするが、完了報告を受けたものや出てきたものについて全く確認をしないマネージャー。
チームメンバーからの「できました」報告を受けていたものが、実はできていなかったことというのは往往にしてある。
チームメンバーの責任でもあるのだが、マネージャーは報告を受けたものに対して確認をしないといけない。
これはエンジニアの作ったものに対してマーケターが管理している際によく見られる。成果物に対して責任を持つのはプロジェクトマネージャーの役割である。

自分のマネジメントのやり方

じゃあ、マネジメントはどうやれば良いのか。

自分が意識していることは下記の二点である。

• まず、何をマネジメントする必要があるのか、マネジメント対象を認識する。
• そうして、どうなればマネジメントしなくて良い状態にまでなるのか、ゴールを見極める。

マネジメントとは「管理」である。じゃあ、「何を」管理するのかを把握する。
プロジェクトだと、そのプロジェクトが達成するために何をしないといけないかを洗い出し、洗い出したタスクについて各メンバーに渡せるレベルにまで分解した上でそれぞれ時間を計画する。
自分が管理するのはそのタスクだと考える。

それでもできないという人へ

マネジメントが苦手という人もいると思う。その時に考えて欲しいのが、ほとんどの人が「体調管理」というマネジメントを普段からしていることである。
今元気かどうか判断する、疲れていると感じたら早めに寝るなど、得手不得手はあるかもしれないが生きている以上はマネジメントできているのである。
また、上記とは違った自分なりの体調管理法を持っているはずで、それは自身のマネジメントの練習の成果なのだと思う。
つまり、誰にだってマネジメントはできるはずだと思う。

最後に

だいぶ雑に書いた感があるし、言いたいことの半分も言えていないような気がするが、上手く伝われば幸いです。

WebRTCを使ってニコ○コ生放送みたいなiOSアプリを作る

はじめに

タイトルは釣りです。多分もう古くて今動画配信といえばInstagramとかTikTokとかライブフリマとかだと思うんですけど
おっさんなので許してください。

概要

WebRTCという技術を知って、今なら無料のサービスだけでこういうの作れるよなとずっと考えていて
去年11月にあのサービスもWebRTC技術を使うことを発表したこともあって、先にやってみました。