ありったけの愛を叫べ

思ったことを書きます。正確でないものを含みます。極力良く言えば素が色濃くでます。

【ミッション失敗】Google HomeからRaspberry Piにコマンドを送り、コマンドを送ったGoogle Homeで音声を再生する

題名の通り、失敗しているので以下の手順は失敗に終わるという情報しかないです。

目的

Google Homeに「明日はなんのゴミの日?」「火曜日はなんのゴミの日?」などのゴミの日をきいたら予め(VOICEROIDなどで)作成しておいた音声を流す。

複数Google Homeがあれば、コマンドを受け付けたGoogle Homeで音声を再生する。

結果

失敗

試み1

IFTTTを利用したソリューション

  • IFTTTのトリガー(this)をGoogle Assistantの変数文字列を受けるものにする
  • IFTTTのアクション(that)をWebhookにする
  • WebhookとしてBeebotteを使う
  • Raspberry PiでBeebotteのchannelにサブスクライブしておく
  • pychromecastで音声を再生する

なぜ失敗判定なのか

IFTTTではトリガーしたGoogle AssistantのIDを取得できない。(試み2を試して気づいたが)それもそのはず、Google AssistantはGoogle Homeとは限らないのでorigin IDというモノを考えてる時点で不毛なデザインになってしまう。

試み2

DialogFlowを間に挟む

そもそもDialogFlowでもIDは取得できないので間に挟むどころか、Webhookに何かを渡す意味すらない。

だがDialogFlowは名前の通りdialogueを作れるものなので、コマンドに対して(対話として)音声再生はできる。

ではなぜ自分にとって失敗なのか。

  1. DialogFlowはGoogle Actionsなので、そのアプリケーションをGoogle Assistantから起動したときのみDialogFlowが介入できる。つまり「対話に入りたいです」とお願いした後に「ゴミの日」の話をする。2ステップになる。
  2. 音声ファイルを非ローカルネットワークにおいておかないといけない。お外の世界にHTTPSでおいておかないといけない。
  3. DialogFlowのWebhookを使ったとしてもコマンドをトリガーしたデバイスIDは取得できない。

以上の微妙に目的から飛び出している要件により、失敗と判定。

ソフトウェアエンジニアリング 例え

他のエンジニアリングを経験したことがないので飽くまでソフトウェアエンジニアリングの話。また、開発方法にも色々な物があるので、これはイチ例えとしてのもの。

 

ソフトウェアエンジニアリングとは毛糸玉を如何に触らずに目的のモノを作り出すかである。

 

作りたいもの:

それぞれ20cmの赤と緑の糸を端どうしで結んだ、ラッピング用のリボン。

 

単位コスト:

  1. 何もせずにいるだけで1秒ごとに1円。
  2. 毛糸だまを触れずに観察すると、1秒間ごとに100円。
  3. 毛糸だまに触れていると、1秒間ごとに1万円。

これぐらいのスケールでだいたい合ってる気がする。あくまでスケールなので実際のコストではない。

当然だが、一人頭にかかる最低限の費用であって、二人同時に毛糸だまに触れていれば毎秒2万円かかる。

 

それぞれが何に相当するか:

  1. これはプロジェクトがあるという事実だけでかかってしまう謎の費用。
  2. リサーチや設計をするコスト。
  3. 実装にかかるコスト。

 

それぞれの説明:

  1. ソフトウェアエンジニアの意識の中に置いておくのにもコストがかかるみたいな気持ちで捉えてれば良い気がする。
  2. ここで毛糸がどのように絡まっているか観察して、効率よく紐解くプランを設計するのが大事である。もちろん顕微鏡を買うのにも追加でコストがかかるのでかなり難しいフェーズ。顕微鏡を買うのかそれとも実際に少し触ってみて(秒間1万円)、要る要らないを判断するのか。とてもむずかしいフェーズである。でもこれは設計中に(設計に)変更を加えるほうが、実装中に(設計に)変更を加えるより圧倒的にコストが安いという結論にも至れる。
  3. なぜ設計より100倍も高いのか。設計より進行が遅いからである。まず設計というものが、実装ではないがゆえに、コードそのものほど細かいことを決めていないからである。設計をもとにコードに落とし込むという思考。さらに実装、コードレビュー、テストなどに時間がかかる。このステップで設計の不備を見つけると、手を離して設計し直すということが稀である。故にこのステップまで入るとコストがものすごくかかる。つまり毛糸だまに触りながら設計を直すのだ。そもそも観察するだけではわからず、実際に触れてみてわかるものというものが多いので、前段階でクリアできなかった問題が浮かび上がったときにこういうことになる。

 

 

『好きと嫌い』の尺度

文章もなにもない。意識の流れをベタ打ちした感じです。

 

何度考えても『好きと嫌い』をスカラーで考えると矛盾することが多すぎる。

好きと嫌いはそれぞれ違う次元が故に『好きと嫌い』を測るなら最低でも二次元ベクトルである必要がある気がする。折りたたみに折りたたんで二次元ベクトル。

「好き。好きは好き。大好きすぎておかしくなりそう。」と一瞬思うことって結構あると思うんですよ。もちろんすぐに自制が働いておかしくなんかならないんですけど。

でもだからといって「でも嫌い。やっぱり嫌い。ふとした言動が嫌い。」みたいな些細そうなものでも嫌いと思うことってやっぱりあります。

だからといって『好き』の値が急に反転して『嫌い』になったわけではなく、好きであり同時に嫌いでもある。これどう考えても二つの全く違う値ですね。

 

それでも話を簡略化するために『好き』か『嫌い』にでばっさり分けたがることが多い。ではこれはベクトルがどこを向いていれば『好き』と『嫌い』なのか。

『好き』が『嫌い』よりも少しでも大きければ好きなのか。それでも好きな部分だけ見ていられれば『好き』なのか。

 

おそらくある程度の閾値を超えたら『好き』や『嫌い』のカテゴリに入り始めるのだとおもう。そもそも興味もない、または知らないものに対しては(0,0)だろう。

 

『明らかに好き』にカテゴライズする場合、『嫌い』の値はおそらく小さいだろう。『嫌い』の値が『好き』に対して大きすぎれば『明らかに好き』ではないだろう。『明らかに嫌い』も然り。

 

では微妙なラインのものはどうだろう。そもそも『好き』<『嫌い』なら『嫌い』というのも成り立たない気もする。自分を例にあげるわけではないが、例えば家族などの切っても切れない人たちとの関係はこういう不等式なこともあるのではないだろうか。

 

 

まとめ:

  • 好きと嫌いはベクトルで考える。
  • カテゴリとしての好きと嫌いはあるのかもしれない。
  • 閾値を超えなければ無関心。
  • 好きと嫌いのカテゴリは線が引けるほどわかりやすいものではない。
  • 好きが嫌い(値)より低くても嫌い(カテゴリ)ではない。逆も。

やっぱり好きと嫌いではなくもっと違う言葉で表せる、私はどっちにでも転べますよ、みたいなカテゴリが必要なのでは。

通勤中でもなく お風呂の中でもなく 寝る直前のベッドの中でもない閃き

結論:

久しぶりに実行時間というのを気にしながらコードを書いてみてやっぱり問題を解くためのコードって最高に面白いなって思った。

 

お話:

プログラマ(もといソフトウェアエンジニア)としてお仕事で書くコードは雑に言えばテストが通ってプロダクション環境で十分早ければわりとOKなことが多い。

後々「そう言えばあそこもっと高速化できるな」などと思っても、コードが既にコミットされている場合Issueやバグをファイルして『後でやる』リストに入るだけということが多い。

それとは違ってプログラミングコンテストやテクニカル面接などで要求されるのは制限時間内に最適解を見つけること。本当の最適解なのか時間制限を鑑みて適切な答えなのかはそこまで重要ではなく、面接官や審査員が「最適」と考えるものを提出できないといけない。

最近ウェブ上のコーディング試験を受けてこれと対峙した。

 

かんたんにルールを説明すると。コードは何度も”テスト”可能で、このテストはソースをコンパイル(ビルド)し自分が定義したテストインプットと向こうが用意したいくつかのインプットを走らせる。必ずしもそのテストインプットは見えない。そして結果が表示される。それとはべつに”提出”すると、結果は見えないが、さらに多くのテストが走る。一度提出してしまえばもうコードはいじれない。という感じ。

 

まずO(N^3)のコードをテストする。おそすぎるというお達し。

O(N^2)にするのに成功。

 

結論から言えば、ここで思考停止してしまったのが悪かった。O(N^2)で十分早いんだなという錯覚に陥った。60分中残り30分も余ってたので適当にコメントでも入れて自分のロジックがあってるか確認して提出。

提出した直後は「楽勝だな」とるんるんだった。るんるんでピアノの練習をした。

 

プログラマにとってもっとも閃きが起きやすいシチュエーショントップ3が「通勤、お風呂(シャワー)、寝る直前のベッドの中」なんてジョークがあるぐらい、特に何も考えなくていい時間でなおかつメモを取りづらい状況で閃きが起きる。

 

答えを提出して数時間後、食事を作ってるときに「そういえば、ああいうのって絶対早い最適解があるんだろうな」とふとおもった瞬間に線形時間の解が頭に浮かんだ。

 

もう悔しい。すぐに実装を初めて20分でできあがって悔しい。O(N)で実行できるのは明らかだし自分で書いたテストも通る。悔しい。20分でできてしまったのも悔しい。30分も余ってたならできるじゃん!さらにもし今の会社で自分が面接官としてこの問題をだしたなら、自分の提出した答えでは受からないだろうということがわかっているのでなおさら悔しい。

課題を提出したあとに「あれもっとうまくできるじゃん」ってことが学生のころは度々あったけどアレよりもっと悔しい。学生のころは「成績に若干響くかもしれないけど他の課題もあるししゃーない」で済ませられた。今回はそうでもない。ずっと悔しがっていられる!ふしぎ!!

 

でもやっぱり自分はこういうのが好きだなってのが再認識できた、やっぱりアルゴリズムって面白いなって。あとこれに限っては『最適解がある』という状況が楽しい。一種のパズルを解いているような気持ちになる。でも今回はルービックキューブの1面だけ色を揃えたのに満足してしまって、他の面を見ることさえ忘れていたようなもやもやが残ってる。でもパズル楽しい!

 

そんな、比較的涼しい夏の日の出来事でした。

 

P.S.

コーディングのテクニカル面接だけを受けて食っていけないかなってちょっと思ったけどそういうビジネスモデルはないのだろうか。

動きというものはすごいんだよ!

自分の記憶の仕方の違いだと言われればそこで話は終わりだし。個人差があるゆえに人の意見に対して論議をしたり批判をするつもりもないので、この話はここで語って終わり。でも少しでも自分の言いたいことを書き出せたらな、と思う。

 

『動き』とは反対にあるものとしてわかりやすいのが写真。写真というのは静止画であって、その瞬間を切り取ったものが出来上がる。事実としてときが流れればそれは過去の記録となる。それを時間がたてば『色あせていくもの』として捉えるかは人それぞれだが。

(写真には写真のいいところがある。だが写真を引き合いにだしてしまった以上、写真が好きな人や写真家には批判に聞こえるだろうがそういう意図はまったくない。動きのあるものとの比較としてあげるだけのつもり。)

 

自分の記憶に残るものはほとんどが動きのあるものだと思う。暗闇で知り合いの顔や風体をみたところで全然相手がわからなかったりする。だけどその人の歩き方のシルエットで9割ぐらいの確信を持てたりする。

自分が『懐かしい』と思うものは仕草や所作や動作だったりする。「こういうふうに扱われるの懐かしいな」とか「たぶん自分が見たのは別人だけど、その仕草懐かしい」とか「親も似たようなことしてたな、今ならあの行動の意味がわかる」など。

 

例えば数年前に自分がみた、きれいな桜並木の写真をみたとする。もう一度見に行きたいなと思い、桜の季節にそこに行ったとする。だが桜並木の直前で耳栓と目隠しをして、ほんの一瞬だけ目隠しを取る。果たしてそれに自分は『懐かしい』という気持ちを抱けるのかという疑問。

『音』、桜の花びらが散る『動き』、自分がそこを『歩いて通った』景色の記憶。それが『懐かしい』なのかなと思う。

 

先に少し出したが、音というのは連続したものとして捉えることがほとんどだと思う。これも一種の『動き』だ。

「このBGMどこかで聞いたことある」「この効果音なんのゲームのだっけ?」「この声どっかで聞いたことある」「この曲なんだっけ?」

こういった疑問は結構頻繁に起こる。自分は「なんかみたことある」というのが比較的少ない。

 

(ロジックも何もなく自分の思うことA,B,Cみたいに並べて「はい結論はこれ」という論理を組み上げられるほど労力を入れて書いた記事じゃないけれど。)

連続的な動作や刺激というのは記憶に残りやすくて懐かしいと感じやすいのじゃないかなって話。

5年先まで計画を立てておくべきという話

*注意:どんなに考えても書き方も内容もポエム風になったので数年後に読み返して恥ずかしくなると思います。

 

大学のアドバイザーに言われたこと。よく考えてみたら高校の時も「どこに落ち着きたいか(着地したいか)で大学を決めろ」と言われたのも似たようなものの気がする。

ある程度安定した生活をおくれてしまうと忘れがちなこと。しょうがないね。勉強勉強の毎日が終わったら仕事仕事の毎日。とはいえ人生ではじめて自立出来るほど稼いだら安定するのを望むのは仕方ないと思う。結婚して〜子供ができて〜などなど人生いろいろ起こったとしても安定するのを望んで、安定したらまたそれを維持したくなる。

それでもある日突然「なにやってんだろ。これ本当に自分が望んでる状況なのかな?」という気持ちになる。ネトゲやソシャゲを数年続けてある日突然「なんで続けてるんだろう?」って気持ちになるのと大変似てる気がする。サイクルの長さとウェイトが多少違う程度で。

 

半年先までしか考えてない、という友人と最近話をしたけど正直半年先まで考えてるのはすごいと思う。半年前の自分は「半年先もやっぱ今の仕事してるんだろうな〜」と漠然と思っててそれになんの感慨もなかったのが今となってはもやもやする。

 

色々な人に話してわかったのが、基本的に5年も継続できるというはなかなかすごいことだということ。それが好きだったけど嫌いになってようが嫌いだったけど好きになってようがずっと好きだろうが嫌いだろうが、5年継続というのはなかなか珍しいということ。ずっと嫌いなものを5年もやるのはかなりいろんな負担がでかいと思うけど。モノにもよるけど、振り返ってみるとやっぱり2、3年で次のことを始めるっていうのはたいして珍しいことではないと思う。

 

というわけでこの先5年のことをどういうふうに考えておくか、を考えてみる。このさき60ヶ月分、毎月の目標をたてるのも面白い気がする、結構悩むタイプだから週末がつぶれそうだけど。DSPの教科書を読み終える。○○を弾けるようになる。あのサイドプロジェクトを始める。みたいなので60個もあげられれば面白いなー。

つまるところ5年というマジックナンバーを用いて、5年先の自分はどう有りたいかで計画するべきというはなし。5年もあれば修士や、頑張れば博士。がんばらなくても別の学士を取って別の職にもつける。意外といい線を捉えているマジックナンバー

Fast, Slow, or Senior

全編英語でお送りします

Been in the software industry for several years, but only working for one rather big tech company, I've recently started to feel that the turnaround for software is long. Much much longer than a lot of other industries.

Maybe I was just fortunate, but for the first few years it felt like I was launching something every year. Regardless of whether it was adding a feature to a product or working on a completely new project.

Then things started to slow down. At least from my perspective it slowed down. It takes years of development as well as jumping through non-tech hoops to get anything launched.

Talking with a few (very limited set of) people, this seems to be a thing with big tech companies. There is "nothing" (very much in quotes) pushing them for a fast turnaround. Suppose a product is already working and you are only adding a feature, there isn't a really big PUSH for it, especially if it isn't an effort driven by a buzz word such as "machine learning".

Now, this is hitting me quite hard on my motivation. Not just the motivation to keep working on a project or staying employed with my current employer, but as a software engineer. I don't feel like I'm accomplishing anything. Anything that I have solved don't get to leave the house as rapidly as I like. But software engineer is such a high paying job and it feels like its hard to get back in once you leave. It is a "golden handcuff", I might not really like it but I have the fear that once I take it off, I might not get the privilege to put it back on.

On the other hand I classify myself as a "puzzle solver", so a launch is not necessary a goal. I like solving puzzles, but once I figure out how to solve the puzzle I lose interest. I tend to consider things as "solved" once I have a patch. The patch would have to go through a code review process in order to get it upstreamed, but I have already lost intersest once I have solved it, so I leave patches up for months. I understand that this is not respectful to people that have put their time to leave review comments on my patches, but I jump on to other puzzles once its solved.

Anyway, I'm starting to lose interest although I still very much love programming. Maybe this is just a consequence of going up the ladder and seniroirty, being assigned tasks that take more time and effort. It might be something that some people find themselves proud about. Nonetheless it isn't quite working out for me. Perhaps it's time for me to move on and go on a new journey :)